There were some questions in Skype about handling disconnections from SQL back ends. While Clarion expects a database connection to stick around forever, this is not typical - and it certainly isnt how SQL back ends achieve their best performance.
Anyhow, disconnects happen, so how do you catch and cure them in your app without having the app close / halt?
While this isnt perfect, it’s something pratik and I tossed back and forth some years ago and had reasonable success with this code. Note: the template part of this is shown to illustrate which embed point this code should be used in (global file manager Throw, for each table).
#AT(%FileManagerCodeSection, ,'Throw','(USHORT ErrorNumber),BYTE'),PRIORITY(4500),DESCRIPTION('') #CASE(%FILEDRIVER) #OF('ODBC') #OROF('SQLAnywhere') #OROF('Oracle') #OROF('MSSQL') IF ERRORNUMBER = 9 SETCURSOR(Cursor:wait) CLOSE(%FILE) SHARE(%FILE) SETCURSOR() RETURN Level:Benign ELSIF ERRORCODE() > 0 and ERRORCODE() <> 33 ! use ODS to log errors here if you wish. ud.debug('detected error # ' & ERRORCODE() & ' FEC=' & FileErrorCode() & ' for file') END #END #ENDAT
We also tinkered with prop:disconnect to try and clean up a timed out connection. We used that to formally close a table so that we could get a successful reopen after that. We had varying amounts of success with this - which was maybe 10 years ago.