Killing an application and subsequent behaviors

Sep 3, 2013 at 1:11 PM
If I kill my application, on next start, my tables don't seem accessible anymore by any mean, or very ultra slow (I did not wait to know how slow). One time I got an OverflowException on SelectForwardStartsWith instead of the slowlyness symptom, which also reappeared on every launch.

I read another post which made me delete the rol files and it did come back to normal. Is that a "good practice"? Is there known issues about that?
Coordinator
Sep 3, 2013 at 1:17 PM
It's not normal behavior, we don't have such one.

Please provide testing solution which repeats such behavior.
Coordinator
Sep 3, 2013 at 1:39 PM
I think I know what you mean.

Your program makes a lot of updates inside of one transaction.
In standard behavior all the data, which must be updated, first is written into .rol file then into data file.

After restarting application, when you first time access any table, the rolled back data must be restored.
HDD's are very slow and restoration procedure can also take the time. All depends upon data quantity.

That's why recommend to use tran.Technical_SetTable_OverwriteIsNotAllowed to have fast updates, random insert and high speed restorations after crashes.
It will take a bit more HDD space thou. Read documenation ref [20130529].
Sep 3, 2013 at 1:40 PM
Yeah that's what I thought too. Except for the OverflowException one. I do have a lot of modifications, but they are delete operations.
Sep 3, 2013 at 1:40 PM
I see the debug output stepping over DBreeze code.
Coordinator
Sep 3, 2013 at 1:42 PM
Use Technical_SetTable_OverwriteIsNotAllowed for deletes also.
Sep 3, 2013 at 1:48 PM
So Technical_SetTable_OverwriteIsNotAllowed boosted my deletions, thanks!
For the restaurations, I have to set Technical_SetTable_OverwriteIsNotAllowed before reading it?
Sep 3, 2013 at 1:52 PM
Nevermind.
Coordinator
Sep 3, 2013 at 1:52 PM
Technical_SetTable_OverwriteIsNotAllowed must be set only in transactions which must modify the table (insert/update/delete).
If transaction needs only to read, then Technical_SetTable_OverwriteIsNotAllowed has no sense.
Coordinator
Sep 4, 2013 at 11:41 AM
If you can see, describe and repeat any issue (OverflowException in this case), please, help to the community, with the description and code for its emulating
Sep 9, 2013 at 9:01 AM
Will do.