OrthoDocSoft
Programmer
Folks,
My app has been alpha-testing for 1 year now with 19 minor revisions and a bunch of your help!
At this point tho', I have not taken into consideration the fact that several machines access the database through wireless connections, and that from time to time, these connections break, and usually, moments later, reestablish themselves. My software makes frequent calls to the database to "refresh" data for these machines, and when these breaks happen, it crashes the software because I don't trap and handle the error.
I think I have determined that this generates an
err# -2147467259 (whew!). So what I'm doing when that error is generated is basically throwing up a warning on the software that the DB is temporarily disconnected, but "continuing" without updating the information. The real-life circumstances that depend on this data can suffer this temporary delay in fresh data.
My question is this: Do you all think that when the wireless connection reconnects that 1) my application and 2) my MSSQL Server database will still "have" their adoConnections intact, so that I don't have to "close" and "open" the adoConnections again? I hope this is true. I cannot test this at home because my MSSQL Service and application are on the same machine (so directly linked). "detaching" the DB destroys the adoConnection (as I would expect) and taking the DB "offline" while the app is running against it, doesn't work. MS SQL Management Studio will NOT take it offline while the app is running against it.
FYI: I count how many times the request for data fails, and after 20 times (about 1 minute), I notify the user that essentially, a fatal disconnection has occurred.
Thanks,
Ortho
![[lookaround]](/data/assets/smilies/lookaround.gif "[lookaround] [lookaround]")
"you cain't fix 'stupid'...
My app has been alpha-testing for 1 year now with 19 minor revisions and a bunch of your help!
At this point tho', I have not taken into consideration the fact that several machines access the database through wireless connections, and that from time to time, these connections break, and usually, moments later, reestablish themselves. My software makes frequent calls to the database to "refresh" data for these machines, and when these breaks happen, it crashes the software because I don't trap and handle the error.
I think I have determined that this generates an
err# -2147467259 (whew!). So what I'm doing when that error is generated is basically throwing up a warning on the software that the DB is temporarily disconnected, but "continuing" without updating the information. The real-life circumstances that depend on this data can suffer this temporary delay in fresh data.
My question is this: Do you all think that when the wireless connection reconnects that 1) my application and 2) my MSSQL Server database will still "have" their adoConnections intact, so that I don't have to "close" and "open" the adoConnections again? I hope this is true. I cannot test this at home because my MSSQL Service and application are on the same machine (so directly linked). "detaching" the DB destroys the adoConnection (as I would expect) and taking the DB "offline" while the app is running against it, doesn't work. MS SQL Management Studio will NOT take it offline while the app is running against it.
FYI: I count how many times the request for data fails, and after 20 times (about 1 minute), I notify the user that essentially, a fatal disconnection has occurred.
Thanks,
Ortho
"you cain't fix 'stupid'...
