In my framework, I test the connection first with something simple like
'select @@version' to see if it is a still-valid connection. If the
SQLEXEC returns -1, then I re-establish the connection.
On 3/3/2020 9:46 AM, Tracy Pearson wrote:
Hi Eric,
I was buried yesterday and didn't deal with email.
Here's some ideas. The SQLSETPROP() in VFP has 3 properties you might want
to investigate.
DispLogin, DispWarnings, and IdleTimeout
DispLogin has an option to never prompt and will throw an error.
The IdleTimeout might trigger a disconnect if the server takes some time to
respond. Thought the default value is to wait indefinitely.
When I have worked with ODBC connections, I have set these settings on
connection 0 before I make any connections. This sets all future connections
in the current session to use these as defaults.
HTH,
Tracy
-----Original Message-----
From: ProfoxTech [mailto:[email protected]] On Behalf Of Eric
Selje
Sent: Monday, March 02, 2020 11:08 AM
To: [email protected]
Subject: ODBC Connection Disconnecting
Hey all,
I've written an app that uploads a bunch of data to an Informix db via
ODBC. It works great, albeit slowly as there are thousands of files and
each file has hundreds of records to upload.
Mostly it works great and I can leave it running unattended for hours, but
periodically the ODBC connection seems to get lost, leaving a dialog on the
screen asking me to confirm the ODBC settings. Hitting [Enter] make it
continue along happily.
I've checked "sleep" settings, set the network card to "never power down,"
checked the router's error logs for any glitches, but can't find a smoking
gun why this happens. Any help thinking this through would be appreciated.
I'm not even sure how to trap for the error when I'm issuing the SQLExec(),
because it's not like it comes back with an Error - it just throws up that
dialog.
Now that I'm talking this through - I wonder if putting it in "Server Mode"
(sys(2335)) when I'm running the SQLExec() *would* cause it to throw an
error instead - one that I can RETRY. I'll get back to you....
Eric
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: https://leafe.com/archives
This message:
https://leafe.com/archives/byMID/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
