I discovered this little trick today.

If you’re wanting to count the number of characters present in a given SQL Server varchar variable, or common, use the following convention

--assuming a search character contained in the variable @SeekChar

--from a variable
SELECT LEN(@StringVariableName) - LEN(REPLACE(@StringVariableName,@SeekChar,''))

--from a table field
SELECT LEN(SomeTableCol) - LEN(REPLACE(SomeTableCol, @SeekChar, ''))
FROM SomeTable

--The Oracle  PL/SQL Variant (for the hell of it).
--All we have to do is replace the LEN function with LENGTH!
SELECT LENTH(SomeTableCol)-LENGTH(REPLACE(SomeTableCol, @SeekChar, ''))
FROM SomeTable

Quick and easy and no annoying looping constructs.

Image by essecento via Flickr

You might be familiar with the following scenario:

You have a SQL Server database server hosting more than one database, but you just so happen to be accessing one in particular from your development environment (Query Analyser, Management Studio, etc).

So, you run a little query to automatically connect you to this database when you connect to the server. You might try something like:

Exec sp_defaultdb @loginame='DOMAIN\UsrNam', @defdb='SomeDatabase';

So, now when you log on, your database is ready and waiting to be used without having to manually select it. I have found this scenario common in development environments, when you are typically running lots of ad-hoc SQL queries, or running in code (stored procedures, views, triggers, etc) against the database.

However if you are working on different databases on the same server, defaulting to a particular one can cause you problems if you need to run in code against a different database. On occasions I have applied stored procedures to the default database, when I meant to do it against another one on the server!

Another consequence is when a development database is refreshed or rebuilt from some external source (from a live environment, for example). Although your default database may exist by name, this is not enough for SQL Server, which fails to log you on and gives the error message:

Cannot open user default database.

You will also get this if you have chosen to rename the database.

So what to do in this instance?

Well, we can defer to the trusty ISQL command line utility, as shown in the following screenshot:

Simply follow these steps:

1. Open a DOS  command Prompt
2. Open up an ISQL Session. I used the following command:
   • -S SQLServer_Name – Specify the name of the SQL Server to which you are connecting.
   • -E – Stipulate to connect as a trusted connection (Windows Authentication)
   • -d master – The database name to which you are going to connect. Here I specified ‘master’

isql -S SQLServer_Name -E -d master

The three options user above are as follows:

Of course, you can connect however you want. For more options (also shown in the screenshot above), type in isql /? for a full list, or refer to the site on the above link.

3. Now run a version of the above script, setting the default database to master

Exec sp_defaultdb @loginame='DOMAIN\UsrNam', @defdb='master';

4. To apply this, enter ‘GO’ on the next line.

This will ensure your SQL Server defaults you to the ‘master’ database in all subsequent connections (unless you change them again). I would counsel this as general good practice, and it comes recommended by a friendly DBA I happen to know.

Does that title make any sense to you?

If not, can you bear with me? I’ll make it worth your while, I promise!

I’ve been looking at a bit of code that threw an error for the first time in nearly a year. This ‘bit’ of code is present on four different environments, and is run under some particularly strenuous and varied conditions.

Here is the gist of the code:

SELECT @var = ISNULL((SELECT col1 FROM SomeTable WHERE col2='SomeValue'), 0)

Those gurus (and some lesser mortals) among us will spot the potential problem immediately. For those, this sort of issue sticks out like sore thumb. But, for the rest of us it isn’t so inherently obvious.

Let me demonstrate. Imagine our ‘SomeTable’ has the following data:

We are assuming that statement we are passing to our ISNULL function will only ever return one result. However, in the above example it does not. You can try it yourself; simply paste the SQL below into your query window:

create table #temp (col1 int, col2 varchar(10));
insert into #temp values (1,'SomeValue');
insert into #temp values (2,'SomeValue');
select isnull((select col1 from #temp where col2 = 'SomeValue'),0)
drop table #temp

You should get the following message:

Msg 512, Level 16, State 1, Line 4
Subquery returned more than 1 value. This is not permitted when the subquery
follows =, !=, <, <= , >, >= or when the subquery is used as an expression.

Understanding the data is key to resolving this. You have assumed there will only be one value, so what are you prepared to accept? Possible solutions include:

select isnull((select max(col1) from #temp where col2 = 'SomeValue'),0)
select isnull((select min(col1) from #temp where col2 = 'SomeValue'),0)
select isnull((select top 1 col1 from #temp where col2 = 'SomeValue'),0)
select isnull((select distinct col1 from #temp where col2 = 'SomeValue'),0)

The first three solve the problem for you in all cases. In the fourth example, the use of the distinct clause will only work if your result set is identical. In fact, it will still break for our example.

But, by putting one of these fixes in place, we are maybe missing the whole point. Although defensive programming can help trap this sort of error, we are overlooking the fact that we have maybe stumbled upon some sort of data integrity error. I.e. do we have two records where we really shouldn’t?

Then the fix is something more fundamental, for example, are we missing a unique constraint somewhere? Here is our table definition with the constraint:

create table #temp (col1 int, col2 varchar(10), constraint UK_COL2 unique (COL2));

Running our original code block with this in place shows up the error when we try to insert a duplicate value in Col2:

Msg 2627, Level 14, State 1, Line 3
Violation of UNIQUE KEY constraint 'UK_COL2'.
Cannot insert duplicate key in object 'dbo.#temp'.

Sure, we still get the error, however, we get it earlier in our process, which is generally better. The is because we may not query these data for some time after it has been inserted, so it may be some time before the original error presented itself. In addition to this, the chances are that if you’ve coded a unique constraint then you’ll be more inclined to test for it.

So, a few things to think about. Principally, what do you want your subquery to return, and is your data correct?

I’ve been playing around with SSRS in SQL Server 2005 recently, and have been particularly encouraged by its potential as a central reporting tool. As part of this  I have been demonstrating how we can SSRS to produce reports from numerous different data sources and providers.

In this particular instance I have been testing its ability to produce reports from the output of an Oracle Package/Procedure and a SQL Server Stored Procedure.  Using the built-in .NET Client I was able to do this quite successfully with little fuss.

It was then brought to my attention that Microsoft are deprecating Oracle Client from ADO.NET 4. This means that, while the code may continue working for some considerable time, going forward it is a better strategy to use an alternative. So, I switched to using Oracle 11g Release 2 ODAC 11.2.0.1.2.

It’s worth noting that for those wanting to utilise an Oracle Stored procedure in SSRS, it must return its data in an OUT REF CURSOR. There are also a few other conditions which you must abide by.  For further info see: Tap into Oracle Databases with SQL Server Reporting Services.

Anyway, on to the problem…

So, as already intimated, all was fine and dandy, until I switched provider. I had set up the dataset on my report, entered the Stored Procedure name, and clicked ‘Ok’. Nothing happened; the IDE just hung.

At this point, I should probably reproduce the procedure in question:

PROCEDURE pck_mypackage.pr_myproc(L_CURSOR out SYS_REFCURSOR)
is
   BEGIN
     OPEN L_CURSOR FOR
       SELECT * FROM MyTable;
   END;

And here the connection string (missing the credentials).

Provider=OraOLEDB.Oracle.1;Data Source=DBSOURCE

Nothing shocking whatsoever, right?

For the first day or so, I took to killing Visual Studio, tweaking a few settings and then trying again. No-one in the websphere seemed to have encountered this; I was baffled. I even resorted to Window’s Process Monitor and trawling through the 1 million+ events it had logged.

So, I decided to confide in my old friend, the bullet-point list. I regaled it with the details of what was working, and what was not. Here it is, replete with the pertinent information:

What Works?

• The stored procedure executes correctly in PL/SQL Developer
• The ‘test connect’ in works fine in SSRS
• A query string of SELECT * FROM MyTable; with Command Type of ‘text’ produces the correct fields in the SSRS report.
• .NET Oracle Provider instead of Oracle OLE DB Provider

What Fails:

• If i change the Command Type to ‘Stored Procedure’ and enter ‘pr_myproc’, when I click ‘OK’ Visual Studio 2005 (service pack 2) simply hangs/crashes.

My attention was drawn to the last three words, “simply hangs/crashes.” It was then I noticed that Visual Studio was not actually hanging completely. I could still click the top-right window buttons; it just seemed to be waiting.

I confided in a friendly DBA, who suggested I looked at the Oracle sessions in an attempt to determine:

1. Whether or not a connection was actually being made, and,
2. What it was doing if the connection was successful

Something must have piqued his interest, because he decided to do it there for me himself.

“Ahhh,” he said, “you’re querying sys.obj$.” He then proceeded to explain to me why exactly this was an issue. The schema we were searching had substantially large data dictionary. This dictionary has to be queried in order to bring back the procedure parameters and the REFCURSOR output.  When looking up the information, the two providers (.NET and Oracle) used two different queries that had a dramatic relative difference in their performances.

Here is the one the Oracle Provider used, taking 10+ minutes:

select * from (select null  PROCEDURE_CATALOG
                      , owner PROCEDURE_SCHEMA
                      , object_name PROCEDURE_NAME
                      , decode (object_type, 'PROCEDURE', 2, 'FUNCTION',  3, 1) PROCEDURE_TYPE
                      , null PROCEDURE_DEFINITION
                      , null DESCRIPTION
                      , created DATE_CREATED
                      , last_ddl_time DATE_MODIFIED
              from all_objects where object_type in ('PROCEDURE','FUNCTION')
              union all
              select null PROCEDURE_CATALOG
                          , arg.owner PROCEDURE_SCHEMA
                          , arg.package_name||'.'||arg.object_name PROCEDURE_NAME
                          , decode(min(arg.position), 0, 3, 2) PROCEDURE_TYPE
                          , null PROCEDURE_DEFINITION
                          , decode(arg.overload, '', '', 'OVERLOAD') DESCRIPTION
                          , min(obj.created) DATE_CREATED
                          , max(obj.last_ddl_time) DATE_MODIFIED
              from all_objects obj, all_arguments arg
              where arg.package_name is not null
              and   arg.owner = obj.owner
              and   arg.object_id = obj.object_id
              group by arg.owner, arg.package_name, arg.object_name, arg.overload ) PROCEDURES
WHERE PROCEDURE_NAME = 'pck_my_package.pr_myproc' order by 2, 3

The second SQL Statement in the union is a particular killer. Here, it joins all_objects and all_arguments tables! I actually ran this query in PL/SQL developer, but gave up after it failed to finish in thirty minutes.

This a particular problem of those schemas with large data dictionaries. I tried this in a smaller one, further up our shipping chain, and it returned in an acceptable amount of time.

In an automatic shipping/deployment system you may find yourself having to determine object/item dependencies, and stipulate a shipping order manually.

For example, when shipping SQL Server code, you might consider the following order of shipping precedence for database scripts:

1. Structural creation
2. Structural changes
3. Relationships
4. Static Data
5. Views
6. Stored Procedures
7. Triggers

Views that depend on other views have to be shipped in the appropriate order, so you will need to consider this as a factor.

In the background we have a dependency table (sysdepends for SQL 2000 and sys.sql_dependencies for 2005/2008).

For the purposes of this article, I am interested in the creation and omission of records from this table for Stored Procedure dependencies.

So, let us create two simple stored procedures, root and dependent like so:

create procedure root as
select 1
go

create procedure dependent as
exec root
go

So problems anywhere, and the execution of dependent works a treat:

exec dependent;

Moreover, when I look at the sys.sql_dependencies table, I see an entry:

select sd.*
from sys.sql_dependencies sd
inner join sys.objects so on so.object_id = sd.object_id
where so.name = 'dependent'

However, when I add these in reverse (I.e. add the dependent Stored Procedure first), I get the following message:

Cannot add rows to sysdepends for the current stored procedure because it depends on the missing object ‘dependent’

With both stored procedures compiled, the code still works as before, however no entry is added retrospectively to the SQL table when ‘root’ is compiled after ‘dependent’

Although this has no practical impact with regard to execution, your ability to perform effective impact analysis for testing and refactoring purposes.

Fortunately, on SQL2005 and 2008, this can be remedied by executing the sp_refreshsqlmodule stored procedure.

And there we have it!

Yes, its out there on the web; a SQL Server Database Version Database. Or, to put it differently, a Database of SQL Server Versions.

Here  you can find a list of all the versions of SQL Server that have ever been released. It even goes right back to version 6.0, released in 1995. Check out the SQL Server Release History if you are interested.

I was drawn to this list when I had two database connections open in my object explorer:

SQLDatabase01 (SQL Server 8.0.2050 – Context/UserName)

SQLDatabase02 (SQL Server 8.0.2039 – Context/UserName)

I was curious as to what the difference was, so investigated further and found the SQL Server Version Database. I found the information I wanted with ease:

2000 (GDR) SP4+Q941203 / 948110 – 8.0.2050

2000  SP4 – 8.0.2039

And looking at the hundreds of different versions available, its not surprising that something like this is needed.

When I starting writing this blog, I was a little unsure as to what to put in it. I knew I wanted it to be mostly programming related, with articles about things that interested me. So I named it my ‘Programming Notebook’ and put into words exactly what I envisaged I’d be putting in it. This is what I put in my About page:

My main intention was for this blog was to be a notebook for myself in a presentable format – an aid to memory of things I’ve found useful on a day-to-day basis, and little snippets I’d like to share. A lot of it won’t be ground-breaking and you’ll almost certainly find it around elsewhere on the net, but it’s presented in a way that I learned it in the hope that others might find it useful.

And later on I started fretting that I was duplicating what already ‘out there’, which is nonsense, because almost everything that anyone writes is already ‘out there’ anyway.

None of this has anything to do with Identity Inserting in SQL Server, but maybe goes some way to explaining why I am writing about something that is well documented ‘out there’.

The reason is that I had to look it up twice. I needed to look it once, and then I forgot, so I needed to look it up again. What I needed was some sort of programming noteb…. hey… I have one!

So here it is:

SET IDENTITY_INSERT [MyTable] ON
INSERT INTO [MyTable] (IDField, Field2, Field3, Field4) values (1,212,2,2)
SET IDENTITY_INSERT [MyTable] OFF

You’ll need to set IDENTITY_INSERT ‘ON’ for the table into which you are inserting, and (for good measure) set it back to ‘OFF’ when you’re done.

You’ll also need to include a field list (which is good practice anyway). The following just won’t work:

INSERT INTO [MyTable] values (1,212,2,2)

So there we are, SQL Server Identity Inserting covered….again.

One of the reasons I like Stackoverflow as a place for asking and answering programming questions is that I

1. Almost always get what I am after
2. Almost always learn something in the process (in answering and asking)

Case in point with a question I asked regarding hierarchy sorting in SQL Server. The question in full can be found on the adjacent link, but, in a nutshell I was looking at how I might sort a variable length hierarchy field in SQL Server 2000.

So, the field value could be 1. Or it could be 1.2.3.4. Or it could be 1.92.333.14.58.62.7.81231.

Given that I needed to sort by the last digit, then the second-last, etc, etc, AND that the length was variable, I found myself a little stumped as to an elegant solution. So I decided to call upon the generosity of the Stackoverflow community

First-up was a number of fixed length solutions, which while good, didn’t quite help. Then I got some help in SQL 2008, which was unfortunate, as I was wanting it in SQL 2000. And then user Vash popped up with an edit to his original post:

Solutions for 2000, 2005, 2008: Solutions to T-SQL Sorting Challenge here.

Marvellous! Here is the solution (modified sightly) that I adopted:

CREATE FUNCTION dbo.ufn_SortByHierarchy(@s as varchar(500), @delimiter as char(1))
  returns VARBINARY(2500)
AS
BEGIN
  DECLARE @pos as int, @r as varbinary(2500), @element as int;

  SET @r = 0x;
  SET @s = @s + @delimiter;
  SET @pos = charindex(@delimiter, @s);
  while @pos > 0
  BEGIN
	SET @element = cast(left(@s, @pos - 1) AS INT);

	SET @r = @r +
	  CASE
		WHEN @element = -2147483648 THEN 0x0000000000
		WHEN sign(@element) = -1
		  THEN 0x01 + cast(2147483647 + @element AS BINARY(4))
		ELSE 0x02 + cast(@element AS BINARY(4))
	  END;

	SET @s = stuff(@s, 1, @pos, '');
	SET @pos = charindex(@delimiter, @s);
  END

  RETURN @r;

END

And, as it turned out, I’d never heard of the varbinary data type, so right there was some extra reading and knowledge for me.

And that, I thought was it. But no! A short while later, user Martin Smith, popped up with a comment.

@James – Not sure what you ended up using. You can also use parsename for this as in this answer: stackoverflow.com/questions/3057532/

A comment! I’d have voted it up if it were an answer. So I followed the link, and voted that up.

So, I also learned about Parsename, which works in lowly SQL 2000 as well. unfortunately, it only works on a four-digit hierarchy, but still useful for me to know about.

So, lots of useful information, new things learned and a permanently documented solution to my problem. That is why I like Stackoverflow.

Not in production environment, anyway!

Recently, I have been involved in implementing functionality that requires a modification to the structure of a SQL Server table. In fact, the nature of the change was a simple addition of a new column to the table in question.

Logic would dictate that that wouldn’t be too problematic. Right? Wrong!

The fact is, that when you use ‘*’ to reference all columns on a table, you’ll make it impossible to perform any reliable impact analysis on your code base. Columns will be used without being explicitly referenced.

If you add more columns to the table in future, who can guarantee that your existing views or stored procedures will actually need them? If you have code in them that performs a ‘Select *’ then they will, regardless. The obvious problem with this is the overhead of returning unwanted data from the database, and the potential degradation of performance inherent therein. However, there is another pitfall surrounding table joins, which I will now attempt to demonstrate:

Imagine you start out with two tables:

create table Test (Id int, code char(1))
create table Test2 (Id int, TestId int, name varchar(10))

And you would like a query that joins these two, so you create a view

create view vwJoinTests as
select t.code, t2.*
from test t
inner join test2 t2 on t.id = t2.testid

You can select from this, no problem

select code from vwJoinTests

A year later, another developer comes along and adds a new column to Test2:

alter table Test2 add code char(1)

Now, the column ‘Code’ exists on both tables.

Selecting from the view is still fine:

select code from vwJoinTests

And, because our original ‘select’ remains intact (it doesn’t break anything), this fault will not be picked up by testing.

But, if I want to reapply the view code, I get the following error:
Column names in each view or function must be unique. Column name ‘code’ in view or function ‘vwJoinTests’ is specified more than once.

Why would I want to reapply the view? Well:

1. You may want to modify it
2. You may want to rebuild a database
3. You may want to install a brand new database on a client site

Technically, 2 and 3 are the same, but I thought I’d emphasise the potential for embarrasment when it comes to your clients.

It also emphasises the point that structural changes to the database, should be accompanied by a full database build test to ensure its integrity has been maintained.

Dynamic SQL is, by its nature, very flexible and often very useful. However, it is this flexibility that can be both a blessing and a curse.

The offical Oracle recommendations on Static vs Dynamic SQL state that, in practice, “static SQL will meet nearly all your programming needs.”

They go on to give a number of conditions under which they deem it acceptable for you to use dynamic SQL. They suggest it is used when one or more of the following items is unknown at precompile time:

• text of the SQL statement (commands, clauses, and so on)
• the number of host variables
• the datatypes of host variables
• references to database objects such as columns, indexes, sequences, tables, usernames, and views

Although this may be true, I would prefer to add the caveat “Only if you absolutely cannot find a way to do it in Static SQL”

They also state:

However, some dynamic queries require complex coding, the use of special data structures, and more runtime processing. While you might not notice the added processing time, you might find the coding difficult unless you fully understand dynamic SQL concepts and methods.

So rather than have a long and tedious discussion as to the relative merits, lets just list the advantages and disadvantages in a series of bullet points.

Advantages

• It gives flexibility and scalability
• It can reduce the number of lines of code written

Disadvantages

• It can become very complex and difficult to read. Think about quotes embedded in quotes, and other such things.
• It can have a detrimental effect on code stability. Some Dynamic SQL errors will not be known until run time. (An example of this is where you reference a non-existent table)
• Dynamic SQL code is harder to test than the equivalent static SQL. It may also be impossible to test for every possible circumstance that your Dynamic SQL will encounter, thus introducing inherent risk.
• It will be more difficult to conduct an effective impact analysis on Dynamic SQL in your code-base.
• SQL injection and misuse – Dynamic SQL is more prone to misuse, and is invariably less safe than static SQL
• The queries code within Dynamic SQL is not subject to a query plan, and as such optimisations may be missed. As such, it can be slower than the equivalent static SQL
• As the SQL query is not known until runtime, it can be harder to performance-tune SQL Dynamic code (for example, determining the indexes that might be required on a table)

So there we are. Take that and pin in on a wall somewhere

Programmers like new toys that they can play with, be it a second monitor, a new IDE, or a new programming language. They also like to feel that they are learning new things and not getting assigned to the technological scrap-heap and so will inherently favour (for example) C#3 above VB6 even when the final solution might be suboptimal.

I found myself drifting into this mindset recently when prototyping a design for component to fit in with an existing framework of COM components.

The component needed to call out to SQL Server 2005 to start an Agent Job. My first instinct was that I had to interface with SQL 2005 Native Client components through the .NET libraries. I envisaged something something like this:

//...get the connectionString somehow...
string connectionString = "Data Source=SOMESERVER;Initial Catalog=SomeDatabase;Integrated Security=SSPI;Provider=SQLNCLI.1;";
OleDbConnection oleDbConnection = new OleDbConnection(connectionString);
ServerConnection serverConnection = new ServerConnection(oleDbConnection.DataSource);
Server oSqlServer = new Server(serverConnection);

JobServer oAgent = oSqlServer.JobServer;
Job oJob = oAgent.Jobs["Test"];
JobHistoryFilter oFilter = new JobHistoryFilter();
oFilter.JobName = "Test";
oJob.Start();

…or something similar therein.

The component would have to expose a COM Interface and be registered using REGASM, which would requrie manual intervension in the shipping process.

In addition to this, I would have neededed to organise for the SQL 2005 Client tools installed on four servers and undertake regression testing of the applications on these servers to inspire confidence that this hadn’t broken anything.

To be frank, it all seemed a little onerous and overcomplicated. Apart from simply wanting to use C#, the reason for this doing this was based on an assumption that I needed the .NET library code to hook into SQL Server and that there was no other way. Really? Have you ever heard such nonsense?

Without realising, I’d very nearly falling into the Second System Effect trap (of sorts). All I really had to do was make a call out to the SQL Server sp_start_job to achieve the same effect, and all I needed was trusty old MDAC 2.8. This meant I could write it in VB6 to fit in with existing framework components with none of the impact or complication inherent with the C#-developed component.

So, I set about writing a little test application as proof of concept. It looked something like this:

Private Sub Command1_Click()
    Dim connection As New ADODB.Connection
    Dim connectionString As String

    connectionString = "Data Source=SOMESERVER;Initial Catalog=SomeDatabase;Integrated Security=SSPI;Provider=SQLOLEDB.1;"

    Call connection.Open(connectionString)

    connection.Execute ("EXEC msdb.dbo.sp_start_job @job_name=N'Test'")

    MsgBox ("Success")
End Sub

But I really wanted to use C#! However,  in this instance it just wasn’t feasible.

So, in conclusion, don’t get blinded by shiny new toys or by a desire to improve oneself, don’t simply dive into the first solution that you come across, and remember, complication is ruination!

This was brought to my attention today, and made for interesting reading:

Oracle Database 11g vs. Microsoft SQL Server 2008

The report claims in its ‘Executive Summary’ that Oracle 11g holds a substantial advantage over SQL Server, and alleges the following high level points:

• Oracle is faster for DBAs to perform administrative functions
• Oracle has fewer steps for standards RDBMS tasks
• Increased Oracle DBA productivity due to lower complexity and higher efficiency
• Oracle has architectural and functional capabilities for backup and recovery beyond those offered by SQL Server
• Oracle demonstrates significant time savings with regard to performance diagnostics and tuning

Later in the Rationale section, however is the following statement:

Oracle has sponsored the studies in response to a challenge made by Edison to Oracle claims that Oracle Database was significantly easier and thus less costly to manage than the other major database management systems.

Which, of course, makes me suspicious. Regardless of Edison’s so-called ‘challenge’, the report is still sponsored by Oracle (and published on their web site), and I would have been surprised if this came back in SQL Server’s favour.

Predictably, Microsoft has published a response denouncing these claims. It alleges the following:

• The report has unverifiable metrics and inconsistent interpretation of results
• The report is not based on ‘real-world; data
• SQL Licensing Costs are cheaper
• Oracle databases consistently suffer from more security vulnerabilities
• Security patching not reflected in true cost of operating Oracle 11g

I’ll not pass comment, but thought it interesting to share!

I’ve been checking whether or not service packs have been applied on SQL Server Installations. I keep forgetting the script that I run to check this,  and having to look it up.

So, here it is:

SELECT SERVERPROPERTY(‘productversion’), SERVERPROPERTY (‘productlevel’), SERVERPROPERTY (‘edition’)

This seems to work in SQL 2000, 2005 and 2008

Taken from this Microsoft link:

http://support.microsoft.com/kb/321185

You could also try

SELECT @@version


Which will give you everything (and more) in a single string:

Microsoft SQL Server 2005 - 9.00.3042.00 (Intel X86)   Feb  9 2007 22:47:07   Copyright (c) 1988-2005 Microsoft Corporation  Developer Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

Go nuts! Here is a free EBook on Defensive SQL Server Programming from Red Gate

Defensive Database Programming with SQL Server

Alex Kuznetsov

ISBN: 978-1-906434-44-1

This leads us to another interesting article:

The Curse and Blessings of Dynamic SQL

I love it when I discover something like this…

I’m querying a table in SQL Server that has over 200 million rows. I’m just wanting the row count. So, naturally, I tried the following:

select count(*) from TABLE_NAME

The query took one minute when it was run initially. And select (1) performed no better. (See: SQL count(1) is not better than count(*))

To be fair, I was quite shocked that it took so long to get this value. Surely there was some value stored internally that I could just pluck out in the blink of an eye?

I searched around for this information, and stumbled across this: How can I get sysindexes information in Sql 2005?

So here it is. Takes no time at all to run:

select object_name(i.object_id) as objectName, sum(p.rows) as rowCnt, i.name as indexName
from sys.indexes i
join sys.partitions p on i.object_id = p.object_id
and i.index_id = p.index_id
where i.index_id <= 1
and i.object_id = object_id('TABLE_NAME')
group by i.object_id, i.index_id, i.name


And, if I need, I can strip out the second-last line to get it for all tables.

As it turns out, you can do the equivalent in SQL Server 2000:

select object_name(id), rowcnt
from sysindexes
where indid < 2
and id = object_id('TABLE_NAME')
order by 2

Which will run in 2005 as well, although its legacy, so we must discourage that! You can tell this, because SQL Management Studio doesn’t colour in sysindexs green, but SQL 2000 Query Analyzer does.