Database connectivity

I have a VB application that connects to a database.  I would like to have this app display connectivity to that database/machine based on a tiered level -just like stoplights (red -- bad, yellow -- ok, green -- good).  How to go about this is up in the air.  Should I run a query and time the query, and find acceptable ranges? Should I ping the machine and base it on response times?  I'm sure other people have done this before, and I'm wondering what they found to be the best practice.

Who is Participating?
Based on the discussion thus far, I think about all you could really do is:
1.Set the stoplight to red at start
2.Set it to yellow and begin to open your connection,query, etc.
3.Set it to green when the connection,query,etc. is established/complete and perhaps report how long that took or back to red if it fails or times out at which time you could report failure or timeout based on the error generated.
How are you connecting (DAO,ADO,RDO...) and to what type of DB?
srobiaAuthor Commented:
Fortunately -- I'm connecting with ADO.  Unfortunately, I'm connecting to MSAccess
Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

Well, just interrogate the state:

Dim Cn as ADODB.Connection
Dim Rs As ADODB.Recordset
Dim Cmd As ADODB.Command
Dim sState as string

Set Cn = New ADODB.Connection
'set rs, cmd, etc...
sState = GetState(Cn.State) 'returns closed?
Cn.Open "Your parameters..."
sState = GetState(Cn.State) 'returns open?
'open rs, cmd.execute, etc...
sState = GetState(Rs.State)
sState = GetState(Cmd.State)

'Get the idea?

Public Function GetState(lState as Long) as String
' State is applicable to Command, Connecton & Recordset Objects
Select Case lState
Case adStateClosed
  GetState = "Closed"
Case adStateOpen
  GetState = "Open"
Case adStateConnecting
  GetState = "Connecting"
Case adStateExecuting
  GetState = "Executing"
Case adStateFetching
  GetState = "Fetching"
End Select

On another note, I guess you could time things if something like performance status is what you are after.  I would use API GetTickCount to see how many milliseconds operations take.  

Declare Function GetTickCount Lib "kernel32" Alias "GetTickCount" () As Long

Dim lTick as Long

lTick = GetTickCount
lTick = GetTickCount - lTick
MsgBox "Something took " & cstr(lTick) & " Milliseconds."
srobiaAuthor Commented:
But what about acceptable times?  I mean I could get the state but if I run it and find that it is fetching after, say 5 seconds, I want to say it is a bad connection.
Do you realize that unless you perform asynchronous operations on your objects you will "stick" on an operation until it is completed?  Synchronously, you will do something like a connection open and this operation must complete before the next statement is execusted.  Asynchronously, you start an operation and resume execution of the next statements immediately, not waiting for completion.  And, if you perform asynchronous operations (as opposed to synchronous) that you have to write code to determine if they are still executing and what state (state here meaning is my connection open yet, do I have data in my input buffer to use although I am not through fetching all, etc...?) they are in?
These kinds of particulars will help define the direction you go in to solve your problem...
On another note, do you realize there are connection and command timeout properties that you can set? For Ex setting:
Cn.ConnectionTimeOut = 5
will generate an error after 5 seconds of trying to connect?
Cmd.CommandTimeOut = 5
would generate a time out error if a query took longer than 5 seconds to execute?
srobiaAuthor Commented:
I'm unsure whether or not I want to make this synchronous or asynchronous.  I was originally thinking that when the load the program that it will perform this check only once (which I know may not be the best-representation of performance).  So I could get away with synchronous.  But I was just kind of wondering what other people have done.  I want to display this to the user -- so, although the timeout property is a great idea -- it doesn't necessarily display performance back to the user.
Well, if the idea is to let the users know when the database is running slow, here are a couple of things to think of.

You could have a timer that goes off every few seconds and runs some standard query which you've timed before.  If the elapsed time (derived through using gettickcount) is in various ranges, you'll assign the proper color to your stop light.....

But, for this to be useful at all, it's going to have to run every few seconds to show the current state of the database.  If you have hundreds of clients issuing this query every few seconds, that alone is going to cause the database to run slow, even if no one is doing any actual work related queries.  

Let's say that you do have up-to-the-minute traffic lights showing the database activity level, do you think that the user will care?  If they need to see a list of clients, they will click the search button no matter what the light says.  The light will only help them to understand that the database is running slow right now.... but, in my opinion, if I run a query, and it doesn't come back right away, I KNOW that the database is not running quickly even without the little traffic lights.

So, the question I'd have is, is it worth all of the database traffic that you are going to be generating, to provide a kind of feedback to the user, that may or may not be that useful to them....
srobiaAuthor Commented:
Yeah up to the minute may not be the best way to do this - -but I was also thinking to do this once (when they launch the application).  But I know that doesn't make the best sense either.  I just think it would be handy to have a nice quick visual for them to see performance -- kind of like BearShare.  I'm trying to compare the pros-cons of doing this.
I think it's a nice idea, and if there was no overhead involved, then I think it would be a nice touch.  But, given the negative aspects, and the limited usefullness, I'd probably table the idea.
srobiaAuthor Commented:
they are all good comments/suggestions.  I would table the idea but it is a nice touch (completely unnecessary though) and it I would gain favor with the users by providing 'pretty' things.  thanks for the discussion
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.