SQL reconnect procedures

stephen barncard stephenREVOLUTION2 at barncard.com
Tue Oct 9 15:44:17 EDT 2012


well "COMMIT/ROLLBACK" should handle the possibility of data loss.

As far as "connections" I've found that there is little time difference
between being 'always connected' and making a connection open and close per
transaction, unless one is hitting it repeatedly for a single result (as I
had to to for a certain database system a few years ago). A greater time
lag is introduced when getting the returned data than the time required to
connect. This is assuming that the DNS is cached; the first fetch will take
longer.

On Tue, Oct 9, 2012 at 11:23 AM, Bob Sneidar <bobs at twft.com> wrote:

> I've been pondering what the ramifications to sql session disconnects are.
> I have seen in other "professionally developed" applications, like our
> accounting software used here, that if the user gets disconnected for
> anything longer than a few seconds, the software completely bails out
> through a series of errors that I have to abort to get the app to quit. Not
> very graceful. I want to make my software more robust.
>
> So I am wondering what happens when there is a transaction in effect, and
> there is an unexpected disconnect. Will reconnecting restore the
> transaction state or is it flushed after the sql timeout? If I can
> reconnect and the transaction is still in effect, well and good, but if I
> proceed as though the transaction is still in effect and it is not, bad
> things could conceivably happen.
>
> Is completely bailing out the best approach after all?
>
> Bob
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 



Stephen Barncard
San Francisco Ca. USA

more about sqb  <http://www.google.com/profiles/sbarncar>



More information about the use-livecode mailing list