Thanks. Somehow my eyes have forever so far missed "seeing"
DmOpenDatabaseInfo() listed in the documentation. However, now I'm confused.
What Jeff said below is what I would like to be the case, and I've no doubt the
misunderstandings are mine, but what they are so far eludes me.
My app runs fine on POSE. It uses expansion card for permanent data storage.
I've just got to the point where the VFS stuff for support of expansion cards
is working right, and so now I'm beginning to debug on a real Dana for the
first time. I've run in crashes the cause of which I've not yet worked out, and
they leave databases open but shouldn't have as I have an abort function which
is supposed to close them all amongst other things. (At least inspection on the
Dana using FileZ / Details / Attr tab shown the Open checkbox ticked for the
databases). Point taken about no crashes allowed for a user, but it would help
me to speed up the debugging cycle if I can avoid having to close the open
databases using FileZ by doing it with some code. A soft reset on my Dana
doesn't do it. After doing the soft reset, if I check the same databases again
using FileZ, they are shown to me as still open. Presumably FileZ is not lying,
or am I missing something? --Bruce
----- Original Message -----
From: Jeff Loucks
To: Palm Developer Forum
Sent: Friday, January 26, 2007 5:41 PM
Subject: Re: Revisiting closing of open databases after a crash
To address your technical question, DmNextOpenDatabase() returns a DmOpenRef.
Use it with DmOpenDatabaseInfo() to get the CardNo and LocalID. Use those with
DmDatabaseInfo() to learn just about anything you want to about the database.
You should be able to identify the ones that are yours, and close them.
Philosophically, I think you haven't heard from anyone, because you pretty
much state the obvious - yes, the developer needs to account for all possible
error conditions. That's just the way it is.
That said, it's possible I don't understand the question. How is it you are
defining an app 'crash'? Usually, a crash on PalmOS means your app has caused a
fatal error and the device has reset. If this is the case, then all open files
have been closed. It's possible all the data hasen't been flushed correctly to
the file/database, but it's been closed.
If your app is otherwise exiting somehow, leaving databases open, that's not
a 'crash', that's a bug in the software. I suggest you find where this is
happening and fix it. When you have found all the places your app is exiting
where it should not, then you have resolved your databases-left-open problem.
On 1/25/07, Bruce Waters <[EMAIL PROTECTED]> wrote:
After a crash, I want my app on next launch to programmatically close any
of its databases left open. There does not seem to be any good way to do this
selectively -- that is, no way to relate the LocalID of a database found to be
open still, to the DmOpenRef returned by using DmNextOpenDatabase in a loop. So
I tried programmatically closing all open databases using the latter in the
loop, with a DmCloseDatabase call for each returned DmOpenRef that was non
null. But there was no way to limit this to just my app's databases, and it
didn't seem to work anyway - well, it crashed the CodeWarrior IDE each time I
tried (my debug target is a real Dana machine), and using FileZ afterwards I
discovered the open databases that appeared to be being closed as I stepped
through in the debugger were still open.
It's looking like I have to build my application in such a way that any
exception likely to result in a 'serious' crash must be caught and the
databases closed down before the effects of the exception destabalise the
running of the app and the crash 'happens'. I can do this most of the time, but
I doubt I can ensure it will never bypass my protection mechanisms when it
crashes (for expediency, and app responsiveness, I have to make assumptions
that most errors won't happen, and just try to catch the more likely ones -
especially memory manager ones); and I despair of having to write an app that
will never crash.
Surely I don't have to tell my users they must have FileZ and learn how to
use it to close the left-open databases manually? (My app maintains about 10, 8
of which are open while it is running.) Opening and closing databases for every
record access would make the app prohibitively slow; but leaving the databases
open while the app runs appears to be an invitation to disaster for users. (My
users will be village people who for the most part will never have used a
computer before.)
Is there a way round this problem? It is making me intensely dislike the
Palm OS as a development environment. Any help out there? --Bruce Waters
--
For information on using the PalmSource Developer Forums, or to
unsubscribe, please see http://www.palmos.com/dev/support/forums/
--
yisdersomenimororsisasisdenderisorsis?
Jeff Loucks -- For information on using the PalmSource Developer Forums, or
to unsubscribe, please see http://www.palmos.com/dev/support/forums/
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
