Forum Posts Feed
UltraRecall stability problems?
< Next Topic | Back to topic list | Previous Topic >
Posted by Graham Rhind
Aug 24, 2007 at 06:48 AM
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
Posted by Alexander Deliyannis
Aug 25, 2007 at 12:55 PM
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
Posted by Ken Ashworth
Aug 25, 2007 at 02:05 PM
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
Posted by Graham Rhind
Aug 25, 2007 at 02:30 PM
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
>
>