I thought I'd start a separate thread on UR stability problems I have been reading about in various other threads. I have been using the program since version 1 in various PC setups and I have only had it crash once --and that was another application's fault.

More specifically, for security reasons, I have relied for quite a few years on the Steganos Safe which creates encrypted virtual drives. I keep my main UR database in such a drive. I once accidentally closed Steganos, therefore virtually disintegrating the drive, while UR was open. When I switched to UR and selected another item UR crashed.

It is possible for such an accident to occur because UR only opens the current item in its database files; therefore UR files can actually be backed up while open by the program. Another application would probably lock the file, and the Steganos Safe would not be closable.

Anyone else willing to share their specific experiences?

alx

That's definitely one of the possibilities.

Other application locking a file is source of problems with a lot of software. It's most often various aggressive antivirus, antispyware and similar programs.

While these above behave non-standardly (perhaps trying to outsmart viruses, implementing even more aggressive hacks to the system), it shall be also treated in the application (UltraRecall in this case). UR shouldn't crash when another item is selected but the database is not accessible - if nothing else it creates bad impression.
It shall display a message, and perhaps retry in a moment (as eg. with antivirus, they usually unlock the file in few seconds), and close the application the "nice way".

Alexander Deliyannis wrote:

More specifically, for security reasons, I have relied for
quite a few years on the Steganos Safe which creates encrypted virtual drives. I keep
my main UR database in such a drive. I once accidentally closed Steganos, therefore
virtually disintegrating the drive, while UR was open. When I switched to UR and
selected another item UR crashed.

Just curious.....If the above situation happened to me, I would immediately do a "Save As" in and save the current database to another safe (non-encrypted non-virtual) drive. Is there a reason why you attempted to keep working with an app that you knew could not longer access the data?

Pretty much any database application (including UR) is going to have a major problem if in the middle of running it the database "disappears". I really don't see this as a UR stability issue as much as an unfortunately situation that happened to you and UR was simply one of the apps that was impacted.....

peace,
PIMfan

I'm no techie but, from my day to day experience using UR for all things data, including web research, writing articles, daily journal, GTD tasking, Bookmarks, Linking to all my HD correspondence, email & documents, etc.on a w2k-sp4 machine, I would not describe the program as having stability problems.

As for backup which has been mentioned, I don't save to an encrypted db but I do back up daily w SyncBack SE, frequently in the background while I'm doing something else w/o conflict.

At the same time I am also running a DSL connection, NOD32 (anti-virus) & Sygate (Firewall) & Macro Express in addition to using memory heavy DAM software + Firefox.

Have I had errors? Sure, I've had a few AV errors that get reported & get fixed but I wouldn't call this program instability & -- in any case & most important AFAIC -- I haven't lost 1 byte of data yet.

This is not to say that others don't have problems with UltraRecall. All I can do is report my personal experience w this product so while I think there are individuals that do have issues, I'm not sure it's fair to characterize the product as having stability issues.

--
Jan Rifkinson
Ridgefield CT USA

I've used UR heavily since it first came out, and I wouldn't call it unstable, either. I've had a couple of crashes, but never any lost data. I've personally found it to be pretty much stable and bug-free.

UltraRecall is built on top of a database, and it is inherent in all database products that data is saved as soon as the user moves off of a record. Keep and eye on the "save" icon and when it gets greyed out to see this in UR.

That being the case, you would normally only be able to lose data from the last record being edited or the whole database if it became corrupted, which is rare. To take account of the latter possibility, most modern database softare has rollback capabilities - it rolls you back to the last known good database before a crash. It's considered good practice to roll back, but it's very annoying when a non-lethal crash causes you to lose all data from a session through rollback.

UR doesn't roll back, so it doesn't lose data.

That's the good part. As I've mentioned in other threads, UR crashes for me with alarming and repetitive regularity, and gives far too many internal access warnings, that it should be able to manage more gracefully (as has been mentioned). I am using UR on my least stable machine (for the good reason that my most stable machine is mission critical and I don't plan to introduce any instability to it), but 95% of my programs work very well on that "unstable" machine. I am less concerned with the crashes in UR (which may be some friction with other programs running) than with the internal errors which Kinook could deal with better. But then, my view is that Kinook fundamentally fails to cater for its less than technical customers and maybe that will change in the future.

Graham

PIMfan wrote:

Just curious.....If the
above situation happened to me, I would immediately do a "Save As" in and save the
current database to another safe (non-encrypted non-virtual) drive.

Can't do that; as I said, UR only loads the current item to memory, so if the original file is inaccessible, you can't save it elsewhere.

Is there a
reason why you attempted to keep working with an app that you knew could not longer
access the data?

Yes: I didn't think about it! As I said, the Safe was accidentally closed. Interestingly, on other similar instances (when I noticed I had closed the Safe) I simply re-opened the Safe before switching to UR and there was no problem.

Pretty much any database application (including UR) is going to
have a major problem if in the middle of running it the database "disappears". I really
don't see this as a UR stability issue as much as an unfortunately situation that
happened to you and UR was simply one of the apps that was
impacted.....

Let me make one thing clear: I started this thread precisely because I have had no real stability problems with UR and I was surprised to read about such problems in this forum. The only reason I mentioned the one instance that UR crashed on me was to point out that I had to do something really silly for UR to crash :-)

So far, only Graham has reported regular stability issues and, as he says, these could be related to other programs.

Cheers
alx

Alexander Deliyannis wrote:

Let me make one thing clear: I started this thread precisely
because I have had no real stability problems with UR and I was surprised to read about
such problems in this forum. The only reason I mentioned the one instance that UR
crashed on me was to point out that I had to do something really silly for UR to crash
:-)

My impression, from following the discussions on the UR Forum, is that the stability issues revolve around Hoisting and Tabs - both new features introduced in v.3. I can't speak to the useage of either of these features yet, and had not experienced any Access Violations until last night.

I was working in a database that contained Folders for Artists and Albums. With focus on the Albums folder, individual Album Items were shown in the Child Pane. I would select the first Album for an Artist, hold Shift, and select the last Album for an Artist, then Alt-L for the Copy/Move/Link popup.

The Album Item has a Form Assigned to it, and upon selecting the first Album Item if I did not wait for the associated Form to load in the Detail Pane before selecting the last Album for an Artist, I would get an Access Violation. This Violation was so servere that it would require a Closing UR.

Once I realized the user behavior that was triggering this event I was able to modify my behavior. I have seen similar behavior in other database programs - allowing one operation (loading the form for a record) to complete before beginning a new one is usually a good practice.

Anyway...

KenA

Interesting. Modern programs should be capable of serial processing commands if they can't handle them in parallel, but in any case, my errors occur even though I always wait for each command to (apparently) finish first. The reason? Because I was getting the impression that the faster I typed, the more unstable UR became. I thought I was going senile, but seemingly there might be something in it :-)

Graham

Ken Ashworth wrote:

Alexander Deliyannis wrote:
>Let me make one thing clear: I started this thread
precisely
>because I have had no real stability problems with UR and I was surprised
to read about
>such problems in this forum. The only reason I mentioned the one
instance that UR
>crashed on me was to point out that I had to do something really silly
for UR to crash
>:-)

My impression, from following the discussions on the UR Forum,
is that the stability issues revolve around Hoisting and Tabs - both new features
introduced in v.3. I can't speak to the useage of either of these features yet, and had
not experienced any Access Violations until last night.

I was working in a database
that contained Folders for Artists and Albums. With focus on the Albums folder,
individual Album Items were shown in the Child Pane. I would select the first Album for
an Artist, hold Shift, and select the last Album for an Artist, then Alt-L for the
Copy/Move/Link popup.

The Album Item has a Form Assigned to it, and upon selecting
the first Album Item if I did not wait for the associated Form to load in the Detail Pane
before selecting the last Album for an Artist, I would get an Access Violation. This
Violation was so servere that it would require a Closing UR.

Once I realized the user
behavior that was triggering this event I was able to modify my behavior. I have seen
similar behavior in other database programs - allowing one operation (loading the
form for a record) to complete before beginning a new one is usually a good
practice.

Anyway...

KenA