Unreliable I'net connection kills ODBC client.

Hi there,

This concerns the generally functional web site
http://www.DrEliza.com<http://www.dreliza.com/>that carries on
discussions about people's chronic health problems, and
sometimes figures things out even when doctors fail. Dr. Eliza is written in
Access 97, with some outboard pieces in VB5.

You enter a statement, which is then put into a DB. Dr. Eliza checks every
few seconds for a new entry, and when found, computes an appropriate reply.

Every day or so, Dr. Eliza crashes. The crash goes through a number of
"stages":
1. First, it throws an Error 3146, with the message "No response from
backend" from the ODBC driver
2. Dr. Eliza then retries, but the next time it gets an Error 3146, but
with the message "Could not send Query(connection dead)"
3. When the connection is restored, it continues to get the "Could not send
Query(connection dead)" message.
4. Eventually after some time, the entire application simply terminates,
Access and all, leaving no trace of any problem.

I secured a copy of the source code, and found the "Could not send
Query(connection dead)" message on the 2nd page of the CC_send_query_append
routine, where it queues the message and returns a NULL, apparently
indicating failure.

This is called on page 4 of the SC_execute routine, which apparently
interprets a failure NOT as a dead network, but rather that it was NOT a
Query command that was being processed.

One of the known weaknesses of C is its lack of alternative error returns or
other mechanisms to jump out of complex code when error conditions are
encountered. This may be a gotcha from this, where things rattle round and
round, perhaps eventually doing something crazy.

All this suggests that Windows ODBC applications are fundamentally
susceptible to unreliable connections. Is this true? Is there a workaround?

All thoughts, ideas, suggestions, etc., are GREATLY appreciated to firm this
site up and start saving lives.

BTW Please CC me at Steve (dot) Richfield (at) gmail (dot) com.

Thanks.

Steve Richfield