>>>>I have not used remote views probably since the mid 90's and am struggling on how to handle this problem. The framework I use has remote views for certain standard system tables (like the Users table) but allows me to access all my specific tables using SPT.
>>>>
>>>>I am having an issue when running my application on a Windows tablet where the connection to the database gets lost or dropped when the tablet goes into sleep mode.
>>>>
>>>>I have adjusted my SPT so that if a dropped connection is detected I retry a few times to re-connect to the database. However, I cannot work out how to do this for the remote views.
>>>
>>>The best approach would be to address the cause, rather than the symptom.
>>>
>>>If your tablet supports Connected Standby, that would probably be the cleanest solution. Even in "sleep" mode, the network connection would stay up: http://www.howtogeek.com/189224/how-connected-standby-works-or-why-your-windows-8-pcs-battery-drains-so-fast
>>>
>>>The next best thing would be to prevent power management from turning off your NIC: http://blogs.technet.com/b/exchange/archive/2013/10/22/do-you-have-a-sleepy-nic.aspx . Many mobile devices by default allow NICs to be turned off, you could experiment with disabling that feature. That's no guarantee your app will continue to work: if the connection has some sort of low-level heartbeat, and your tablet in sleep mode doesn't respond to that, then the connection may be dropped at the server end anyways.
>>>
>>>If that doesn't work, the next step is to prevent sleep, or make the inactivity timeout for sleep mode so long that it effectively never goes to sleep.
>>>
>>>If none of that works, then you'll have to try to work around it. Probably means diving into your framework and wrapping calls in connection retries, similar to what you've done with your SPT.
>>
>>Al, in a mobile environment YOU MUST cope with the issue that connections can be dropped. There is no way around that.
>>Our large scale VFP application just reconnects to the database very transparantly with minimal code in a robust way. RV and CursorAdapters come to live again by just telling VFP that the connection died on you.
>>
>>

ASQLHANDLES(aSqlhndls)
>>FOR EACH nOdbchdbc IN aSqlhndls
>>	=SQLIDLEDISCONNECT(nOdbchdbc)
>>ENDFOR

>>
>>Our application checks every 5 seconds if the connection is still alive, if not, it calls the code above. The when doing a requery() VFP attempts to reconnect to the database.
>
>Yes, in the general case you have to handle disconnections, because they can happen even with "perfect" networking. But, the measures above should reduce disconnections due to sleep, which was the OP's original complaint. Depending on the use case, that may be good enough.

That is not quite what it does. It is causing the connection to build up automatically again at next activity on the connection handle, even if it was broken before.

>Your code sample is interesting - but if the workstation goes to sleep, does your heartbeat code keep going or does it stop?

It stops, but that is irrelevant. When it wakes up again, it will run the code above and get the connections fresh and alive again, even if days later, after several restarts of the server, etc.

Walter,