At 02:17 PM 3/06/2004 +0000, you wrote:

>Hi
>below are accurate reported states of my TIBODatabase connection
>status using ConnectinStatus and VerifyConnection. I am finding it
>impossible to tell if my database is actually connected by means of a
>status. Is running an arbitary query the best way to check your
>database is connected? If result do you do `real' stuff otherwise
>(on isc error on query) assume the database is not connected? If I
>did get an error do I try and connect the database again AND run the
>arbitary query again?
>
>TIBODataset = DB
>
>DB.ConnectionStatus = DB_CS
>
>DB.VerifyConnection = DB_VC
>
>I start the app (DB.Connected = false)
>
>DB_CS = csDisconnected
>DB_VC = True (Connected)
>
>I then go DB.Connected := true;
>
>DB_CS = csConnected
>DB_VC = True
>
>I now pull out the newtowrk cable on my PC
>
>DB_CS = csConnected
>DB_VC = False
>
>I run a query ­ query returns error ­ the above status is the same.
>
>I plug my network cable back in ­ above status the same
>
>I run a query ­ same error (could not connected to host) ­ above
>status the same.
>
>I ForceDisconnect
>
>DB_CS = csDisconnected
>DB_VC = True !!!!
>
>I DB.Connect = true
>
>DB_CS = csConnected
>DB_VC = True
>
>OK ­if you think at this point things are a little unpredictable
>
>Now DB.ForceDisconnecct
>
>DB_CS = csDisconnected
>DB_VC = True
>
>Now pull out the network cable
>
>DB_CS = csDisconnected
>DB_VC = True
>
>The EXACT opposite staus situation the last time I had no network
>connection.

Looks as if you had a lot of fun...but simply throwing things at in random
order is bound to cause this sort of mess.

May I suggest you think through the sequence of events regarding a
connection, anticipate the exceptions, read flags and call methods
appropriately?

Connect sets up a whole bunch of things on the client, apart from
attempting to connect to the server. An abruption of the connection won't
unset any flags or statuses - it's just code - the Connected property stays
true until you explicitly call a method that causes it to go false.

There's only one way to know that the connection has been lost and that's
to throw a request down the wire. If there's no wire, you'll get an
exception. It will be one of a group of very specific exceptions, which
your global handlers can listen for. The handler can respond by calling
VerifyConnection which will confirm the situation by returning False and
setting ConnectionWasLost to true.

I'm not certain but I *think* an ordinary call to Disconnect will succeed
if ConnectionWasLost is true. In any case, if you put the Disconnect call
inside a try..except block, you can ultimately call ForceDisconnect if
Disconnect fails.

Now all the flags should be in a state where you are ready to call
Connect; but you should test the Connected property before calling
Connect, just in case, and retry, to ensure a smooth reconnect. But don't
go into an interminable loop here on the assumption that the reconnect will
eventually succeed. You also need to allow for the possibility that the
server crashed and didn't restart.

Get into the habit of calling methods, rather than setting the properties
that become true or false when the methods succeed. Call methods, test
properties. You get more elegant (read: trackable) code this way and also
save some processing cycles.

Helen