Dane, >The backend is _very_ brittle ...
Sounds like an accident waiting to happen. When a system can't be maintained reliably, the reliability goes down. <g> I realize the point is moot for your present scenario, and you have to play with the cards you are dealt. In times like these you have to live by the golden rule: "He who has the gold, makes the rules." <g> And your client has the gold. >Believe me, I've thought of both your options already, and they don't work >in this case :P More details below. (snip) >So then with your suggestion using the temp database, the following scenario >is possible: Can I assume you are using a custom conduit? If not, I'd suggest doing so. In your app, keep an application preference (or whatever) set to denote an edit is in process but is not yet completed and verified. Allow your application to quit and resume per previous suggestions. In the conduit, first get the application preference and test whether any operations are only partially complete. If so, disallow *any* exchange of data (for that creator ID) and log a message that Hot Sync is not allowed with pending edits. This will allow the user to resume where they were and complete their set of records, clearing the app preference flag. The next Hot Sync can than occur normally, sending back the complete set of original records and accepting a new set. > . . . so we are back to needing to trap appStopEvent. I think all you need to do is disallow the Hot Sync, and you should be able to accomplish this in your conduit code without any impact on the back end server. From the server's standpoint, an aborted Hot Sync can leave the server files exactly as they were -- it wouldn't need to know a Hot Sync was attempted. Or at least that is my .02, Doug -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
