John,

To give some counterweigth to Cetins answer. We are doing what you are trying to do: Recovering a SQL application from a disconnect.

Though not every situation is simulated and tested, I can confirm that it is possible to recover your views and continue working as before. Preliminary testing shows that in our case we are able to recover, though it needs further testing.

We use a shared connection handle which is stored in applic.Sqlhandle. We use a access hook and execute a blank SQLEXEC() to check whether the current connection is alive.

LOCAL nHandle, cString, nSel
nHandle = 0

nSel = SELECT()
DO CASE
	CASE THIS.KeyTimepassed("CHKSQLCON", 3)
		** dont do this twice in three seconds
	
	CASE SQLEXEC(THIS.SqlHandle, "") = -1
		*** Oh-oh, we lost SQL server connection. Lets try to reconnect
		WAIT WINDOW "Connection to database is broken. Trying to reconnect" NOWAIT
		
				** Rollback all transactions
		FOR nT = 1 TO TXNLEVEL() 
			ROLLBACK
		ENDFOR
		
		** Close all views
		FOR nT = 1 TO AUSED(aTables)
			IF CURSORGETPROP("SourceType",aTables[nT,2]) = 2
				=TABLEREVERT(.T., aTables[nT,2])
				USE IN (aTables[nT,2])
			ENDIF
		ENDFOR
		
		cString = SQLGETPROP(THIS.SqlHandle,"ConnectString")
		
		#IF VERSION(5) >= 900
			ASQLHANDLES(aSqlhndls)
			FOR EACH nOdbchdbc IN aSqlhndls
				=SQLIDLEDISCONNECT(nOdbchdbc)
			ENDFOR
		#ENDIF
		
		DO WHILE nHandle =< 0
			WAIT WINDOW "Connection to database is broken. Trying to reconnect" NOWAIT
			nHandle = SQLSTRINGCONNECT(cString)
		ENDDO
		WAIT CLEAR

		THIS.Sqlhandle = nHandle
ENDCASE
SELECT (nSel)
RETURN THIS.sqlhandle

>I am considering conversion of my backend from VFP to SQL Server.
>
>This is an application with over 700 views from approximately 50 tables in a single database.
>
>It is a financial application. Portions are executed from roaming wireless workstations. We do have many disconnect problems with these wireless workstations. We have it under control for existing installations (usually), but each new installation seems to have it's own unique issues when getting the wireless network to become stable.
>
>In case it matters, my application (the executable) is running locally on the client and the server is where the database resides, probably the most common setup.
>
>My question is very specific. It effects my priority with regard to switching from a VFP engine to SQL Server.
>
>Question:
>
>Using FoxPro as the database engine, my application is running. A list of accounts is on the user's screen. The user isn't doing anything. No key or mouse activity is occurring. The foxpro code would be sitting on a READ EVENTS line. At least 10 views are probably open.
>
>I reach and disconnect the ethernet network cable, leave it disconnected for 5 seconds, then plug it back in.
>
>The user clicks the Requery button and the app crashes because a disconnect had occurred even though it is now re-connected. Yes I can and do capture the error and inform the user that the app can not recover from the disconnect and will basically crash. I do not expect to ever find any reasonable method to fix this while using VFP as the database engine.
>
>This is normal FoxPro behavior. I understand that. I accept that.
>
>This crash will NOT occur once I switch to SQL Server backend because there would be some means to just reconnect to the database or something like that.
>
>True or False?
>
>Thanks,
>John