Alan Pinstein wrote:
> Did you see my post? I've found the same problem
Yes thanks, you got it exactly. But I'd already written that painfully
detailed analysis and didn't want to discard it. :-)
> The only thing that I can think of for you to do is to NOT delete the
> temp DB, but set a flag somewhere to delete it.
That would work, though now I just open the temp db and delete all the
individual records. Either way would be fine in my case. But one
reason for actually deleting the temp at reset time is to help recover
from any crash caused by filling up the storage heap. Not that my app
necessarily crashes in that case(!), but if some other app does, then my
app tries to be a good citizen by reducing its own footprint.
Also, the temp data in question, if it gets corrupted through some
unknown bug in my app, can crash my app. So by deleting and rebuilding
the temp data, such corruption is self correcting with minimal extra
code bloat. It only slows down the next startup. (Of course this will
NEVER happen to users in the released version...)
> Then the next time your app [...] is called from a find, delete
> the temp DB.
I'd bet it would fail in the Find launch code the same way it fails in
the Reset launch code, since the same basic logic is executing.
-slj-
