By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,304 Members | 3,201 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,304 IT Pros & Developers. It's quick & easy.

Recognizing if SQL Server is installed (and what version)

P: n/a
Hello,

I have an application which I'd like to determine if SQL Server is
installed, and if so, what version. Is there any way to do this outside of
error trapping?

Thanks!
Rick
Oct 17 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Not sure if it will work, but you could scan the registry, or even
search harddrive for the exe. It would probably be quicker to to just
use error checking though.

Just my 2 cents,

Seth Rowe
Rico wrote:
Hello,

I have an application which I'd like to determine if SQL Server is
installed, and if so, what version. Is there any way to do this outside of
error trapping?

Thanks!
Rick
Oct 17 '06 #2

P: n/a
Try to connect with a sqlconnection to (local) using integrated security
If it fails to connect, it is not installed, or the current user has no
rights to connect (check error).
If it is connected, you can read the version from the ServerVersion
property.

Rico wrote:
Hello,

I have an application which I'd like to determine if SQL Server is
installed, and if so, what version. Is there any way to do this outside of
error trapping?

Thanks!
Rick

Oct 19 '06 #3

P: n/a
This is probably the only "prpper" way to do this. Unfortunately, the
OP said he didn't want to do any error trapping (which I assumed meant
he didn't want to try to connect to the server) - but I say "to bad!"
:-)

Thanks,

Seth Rowe
Theo Verweij wrote:
Try to connect with a sqlconnection to (local) using integrated security
If it fails to connect, it is not installed, or the current user has no
rights to connect (check error).
If it is connected, you can read the version from the ServerVersion
property.

Rico wrote:
Hello,

I have an application which I'd like to determine if SQL Server is
installed, and if so, what version. Is there any way to do this outside of
error trapping?

Thanks!
Rick
Oct 19 '06 #4

P: n/a
I never understand the questions where the "programmer" doesn't want to
use exception handling. I always wander what such applications look like
(and how they work) ....

rowe_newsgroups wrote:
This is probably the only "prpper" way to do this. Unfortunately, the
OP said he didn't want to do any error trapping (which I assumed meant
he didn't want to try to connect to the server) - but I say "to bad!"
:-)

Thanks,

Seth Rowe
Theo Verweij wrote:
>Try to connect with a sqlconnection to (local) using integrated security
If it fails to connect, it is not installed, or the current user has no
rights to connect (check error).
If it is connected, you can read the version from the ServerVersion
property.

Rico wrote:
>>Hello,

I have an application which I'd like to determine if SQL Server is
installed, and if so, what version. Is there any way to do this outside of
error trapping?

Thanks!
Rick

Oct 19 '06 #5

P: n/a
Dear Rick,

To check if SQL Server is installed, you can check if this registry key
exists: HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\Microsoft SQL Server

For the version, I'm not sure since I don't have different versions of
SQL Server installed.
On my computer, the registry path
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\Microsoft SQL
Server\80\Tools\Client Setup\Current Version
exists. In this key, you can read the string "CurrentVersion". In my
case it's 8.00.194.

Best Regards,

HKSHK
Oct 19 '06 #6

P: n/a
The only reason is to avoid them is because try catch statements can
add a lot of overhead if used excessively.

Thanks,

Seth Rowe
Theo Verweij wrote:
I never understand the questions where the "programmer" doesn't want to
use exception handling. I always wander what such applications look like
(and how they work) ....

rowe_newsgroups wrote:
This is probably the only "prpper" way to do this. Unfortunately, the
OP said he didn't want to do any error trapping (which I assumed meant
he didn't want to try to connect to the server) - but I say "to bad!"
:-)

Thanks,

Seth Rowe
Theo Verweij wrote:
Try to connect with a sqlconnection to (local) using integrated security
If it fails to connect, it is not installed, or the current user has no
rights to connect (check error).
If it is connected, you can read the version from the ServerVersion
property.

Rico wrote:
Hello,

I have an application which I'd like to determine if SQL Server is
installed, and if so, what version. Is there any way to do this outside of
error trapping?

Thanks!
Rick

Oct 19 '06 #7

P: n/a
Agreed.

You only use these constructions when needed.
It is better to avoid exceptions where possible, by doing the proper
checks before executing the statements. But there will always be
exceptions in a program that must be handled.

The problem I detect in the question of Rick, is that he is using the
word "Error trapping", instead of exception handling; an exception is
not always an error.

The problem with another way of SQL Server checking(like the registry
way provided in the reply of HKSHK) is that the registry entries are
changing when new versions of SQL Server are released; SQL 2000 version
is stored in Microsoft SQL Server\80, SQL 2005 in Microsoft SQL
Server\90, SQL 7 in Microsoft SQL Server\70, SQL 6.5 - I don't know. And
maybe the next version will use a complete other path, or even no
registry settings at all. Another problem is that you may know that it
is installed, and what version it is, but if you don't know if it is
running (or if the user has the right to connect to it) you still have
to apply a try catch block to a connection to this instance.
rowe_newsgroups wrote:
The only reason is to avoid them is because try catch statements can
add a lot of overhead if used excessively.

Thanks,

Seth Rowe
Theo Verweij wrote:
>I never understand the questions where the "programmer" doesn't want to
use exception handling. I always wander what such applications look like
(and how they work) ....

rowe_newsgroups wrote:
>>This is probably the only "prpper" way to do this. Unfortunately, the
OP said he didn't want to do any error trapping (which I assumed meant
he didn't want to try to connect to the server) - but I say "to bad!"
:-)

Thanks,

Seth Rowe
Theo Verweij wrote:
Try to connect with a sqlconnection to (local) using integrated security
If it fails to connect, it is not installed, or the current user has no
rights to connect (check error).
If it is connected, you can read the version from the ServerVersion
property.

Rico wrote:
Hello,
>
I have an application which I'd like to determine if SQL Server is
installed, and if so, what version. Is there any way to do this outside of
error trapping?
>
Thanks!
Rick
>
>
Oct 20 '06 #8

P: n/a

Rico napisal(a):
Hello,

I have an application which I'd like to determine if SQL Server is
installed, and if so, what version. Is there any way to do this outside of
error trapping?

Thanks!
Rick
Hi, i use this code to check about running instances, which can also
provide information about version. I know it's not 100% what you
looking for, but perhaps will be useful:
Imports System.Data.Sql
Public class test
Private _list_inst As SqlDataSourceEnumerator

Public Property list_inst() As SqlDataSourceEnumerator
Get
Return _list_inst
End Get
Set(ByVal value As SqlDataSourceEnumerator)
_list_inst = value
End Set
End Property

Private Function listservers() As DataTable
list_inst = Sql.SqlDataSourceEnumerator.Instance
Return list_inst.GetDataSources
End Function
end class

Function listservers return datatable with current installed and
running (!) instances. There is column called version.

Greeting
PK

Oct 26 '06 #9

P: n/a
Rico,

Execute this select statement:
SELECT @@VERSION

Cheers,
Rob Panosh

Rico wrote:
Hello,

I have an application which I'd like to determine if SQL Server is
installed, and if so, what version. Is there any way to do this outside of
error trapping?

Thanks!
Rick
Oct 27 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.