Scott-
Did you see my post? I've found the same problem, but in my case I can have
the 'rug' put back by passing 'newSearch == true' to the search routine...
maybe there is a specific return variable you can pass back to
SysBroadcastActionCode that will do the same thing? I just checked the
sources, and that isn't the case. 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. Then the next time your app launches, or is called from a find, delete
the temp DB. Kinda messy, but it won't crash.
Alan Pinstein
Synergy Solutions, Inc.
http://www.synsolutions.com
1-800-210-5293
>Bob Ebert wrote:
>> I can't think of any reason why DmDeleteDatabase would crash during a
>> reset launch code loop. Maybe you accidently tried to use some global
>> variable? I'd love to see the stack trace for this.
>
>One stack trace coming up:
>
> __Startup__ <== UIAppShell, not my app
> PilotMain
> SysBroadcastActionCode
> DmGetNextDatabaseByTypeCreator
> MemLocalIDToLockedPtr
> MemHandleLock
> PrvHandleCheck
> ErrDisplayFileLineMsg <== "MemoryMgrNew.c, Invalid handle"
>
>See what's going on? My app is called for reset and calls
>DmDeleteDatabase to delete its temp database. Then my app exits
>successfully back to SysBroadcastActionCode, which then tries to iterate
>to the next app to call. But the deletion has pulled the rug out from
>under the iteration, so it crashes shortly after.
>
>This behavior is sensitive to the relative ordering of my application db
>and the deleted db in the iteration. If the temp db is newer than the
>app (the usual case) then it crashes, otherwise it succeeds.
>
>Final clue: this crash happens on 3.0. It runs correctly on 3.1.
>
>-slj-
