Much thanks, Ted. I hadn't thought about using my timer to simply
disconnect if there hasn't been any traffic in "X" minutes, and throw
away the connection handle. I'm thinking maybe 2 minutes...but I suppose
it depends on how long the reconnection takes. Have to do some testing.
Is there a way to test an existing sqlstringconnect() connection handle
to see if it's valid, without throwing an error? Or should I just trap
for the 1466 error and deal with it accordingly?
Thanks again for the wize-ness!
Mike
-------- Original Message --------
Subject: Re: Client--Server via Internet
From: Ted Roche <[email protected]>
To: [email protected]
Date: 6/4/2013 8:16 PM
Oops. Hit 'Send' too soon.
Long answer: you're bring the Achille's Heel of FoxPro, the need for a
stable, long-term connection to the data, and transporting that to "the
cloud."
The internet was designed to survive nuclear war, but it doesn't guarantee
your connection won't get re-routed and need to reconnect after the blasts.
If you're only using the data infrequently, it's better to be a good 'net
citizen and not consume all the resources while idle.
At the same time, yes, there is a cost to connecting and that could slow
down the app's responsiveness. The optimal solution is to disconnect when
idle but not between every transaction. If you route your data processing
through a central data object, consider keeping the connection there. Keep
the connection going with a timer that disconnects once it times out,
perhaps five minutes. Reset the timer each time you do a data access.
Reconnect if you test the connection and it's not responsive, or when you
know you've intentionally disconnected. This way, the data will be
responsive while it's in use, but not consuming resources when
long-term-idle.
On Tue, Jun 4, 2013 at 9:09 PM, Ted Roche <[email protected]> wrote:
Short answer: Yes.
On Tue, Jun 4, 2013 at 6:00 PM, Mike Copeland <[email protected]> wrote:
My VFP app connects to a MYSQL (soon to be a MariaDB) server running on a
dedicated Linux box via the Internet. My current design is that when the
app starts up it connects to the MySQL server and then keeps that
connection 'live' by using a timer every 15 minutes, sending 'SELECT
@@identity' in case there is no user activity.
I'm running into frequent situations where the workstation's Internet
connection seems to be getting dropped briefly (by the ISP) and the next
attempt to access the server by the app on that workstation will trigger
"there is no connection" errors. (loosely paraphrased) The app then
reconnects and moves along.
Would it be smarter to
- connect when needed
- send/get data needed
- disconnect
each time I need to access the server? I had avoided this assuming it
would slow things down during the connection process, but, maybe this would
be preferable?
I know that testing is the best way to figure this out, but I'm sure this
is old stuff to many of you and you've already been there done that.
Thanks for any wisdom or opinions.
Mike Copeland
______________________________**_________________
Post Messages to: [email protected]
Subscription Maintenance:
http://mail.leafe.com/mailman/**listinfo/profox<http://mail.leafe.com/mailman/listinfo/profox>
OT-free version of this list: http://mail.leafe.com/mailman/**
listinfo/profoxtech <http://mail.leafe.com/mailman/listinfo/profoxtech>
Searchable Archive:
http://leafe.com/archives/**search/profox<http://leafe.com/archives/search/profox>
This message: http://leafe.com/archives/**byMID/profox/51AE636B.6050800@*
*ggisoft.com<http://leafe.com/archives/byMID/profox/[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.
Report [OT] Abuse: http://leafe.com/reportAbuse/**
[email protected]<http://leafe.com/reportAbuse/[email protected]>
--
Ted Roche
Ted Roche & Associates, LLC
http://www.tedroche.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[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.
