• Welcome to SQLitening Support Forum.
 

News:

Welcome to the SQLitening support forums!

Main Menu

Never Use slDisconnect(?)

Started by Frank W. Kelley, November 11, 2015, 06:01:53 PM

Previous topic - Next topic

Frank W. Kelley

This is apparently a resolution to a problem discussed at length in this thread.

The program I'm working on allows users to switch between a local database and a server-hosted database. A selection window allows them to enter the server host's name or IP address, then test the connection. On the local machine (LocalHost) that is running the server, the code executed without fail every time. But when I ran it on a client machine, the switch between databases would freeze on the second call to slConnect.

The solution (after MANY hours of troubleshooting) was to remove all instances of slDisconnect (and slClose) in my switching code. To switch from one database to another, simply execute an slOpen (for the local DB) or slConnect followed by slOpen when switching to the server. The switching code now works flawlessly on all the test machines.

The clue was in an old post by Fred where he explained there is only a single handle used for the database. When you open a new handle the previous one is forgotten.

If you're experiencing a freeze problem when switching/opening databases, this could be the answer.

Frank W. Kelley

I originally went the pop/push route and still had problems. This solution is solid for my situation. I offer it for those who might experience the same problem and need a fix that works.

Bern Ertl

#2
Quote from: Frank W. Kelley on November 11, 2015, 06:01:53 PM...
The solution (after MANY hours of troubleshooting) was to remove all instances of slDisconnect (and slClose) in my switching code. To switch from one database to another, simply execute an slOpen (for the local DB) or slConnect followed by slOpen when switching to the server. The switching code now works flawlessly on all the test machines.
...

Frank, slConnect checks if you are already connected and aborts if you are.  Did you test consecutive calls to slConnect with different servers and it worked (ie. it connected to the second server)?

<original msg deleted - see complete solution to this problem posted in this thread:  http://www.sqlitening.com/support/index.php?topic=9420.msg24904#msg24904 >

cj

#3
I have had no connect/disconnect problem remarking the 2-lines below in SQLiteningClient.Bas, but CloseHandle thMutex is only closed for the last connection when the DLL unloads if this correction is made.
thMutex appears to be more than just a mutex to separate messages from ImHere requests sent to the server.
WaitForSingleObject is used with it so CloseHandle thMutex must be in the correct location.

I am not 100% sure with FreeLibrary.
Once a DLL is loaded not sure it should be unloaded before program termination.
The correction below is to SQLiteningClient.bas and Berns' is to SQLitening.bas.

If there are any mutex experts out there, please step forward.

Correction to SQLiteningClient.Bas:
SUB SQLiteDisconnect ALIAS "SQLiteDisconnect" EXPORT
  ' Tell ImHere thread to die
  @tlpKillImHere = 1
'reset tlpKillImHere  ' Disconnect and close Tcp socket  DoRequest %reqDisconnect, 0, 0, "", 0
  TCP CLOSE thSocket
'CloseHandle thMutex
END SUB