This is going to hurt a little

Imaging a 5100 line stored procedure that is doing a conversion of some data. After hundreds of site updates, you get called in to find a wee little bug that seems to have no consistent behavior but it is definitely in the conversion. Then some where in that 5100 lines of code you find these snippets - several hundreds of lines apart but interacting just as viciously:

CREATE TABLE #Duplicates
(
RecID INT IDENTITY (1,1)
,i_id INT
, and other things
)

..eventually some insert code fills this temp table. Later we find this new table:

CREATE TABLE #Itemslist
(
RecID INT IDENTITY(1,1)
,INo INT
, and other things
)

...which also gets properly loaded. Eventually final results are loaded into yet another temporary table. I will spare you the details and just point out the join here;

SELECT some stuff
FROM #Itemslist il
JOIN #Duplicates d ON il.RecID = d.RecID
JOIN etcetera

Fortunately the duplicate table was very small which is the only thing that contained the error that propagated from this.

Where else does one equal zero?

From more of the old code from Hyberia: We figure that this is the lazy man's (person's) method to making insert tables without all that messy typing.


SELECT rlk.*, rlk.i_id as i_id2 --CREATE #RSLAG table
INTO #RSLAG --note.. the i_id2 column was added to
FROM RSLAG rlk --cause the original i_id column to be
WHERE 1 = 0 --created without the IDENTITY property

SELECT rlk.* --CREATE #RSLAG_total table
INTO #RSLAG_total
FROM #RSLAG rlk
WHERE 1 = 0

Query to NoWhere

In a three hundred line stored procedure (not bad) one developer noted that the performance issue came down to the corrolated sub-query. Upon inspection, this left-joined monster was not even referenced by any output column, where clause or reference.

What a FIND!

SELECT
a_bunch_of_stuff
FROM #RPT_ORDERS ot
LEFT JOIN (SELECT
Another_long_painful_query
FROM #RPTEXTRA toc
INNER JOIN A_BUNCH_OF_STUFF_TO_MAKE_IT_EVEN_SLOWER tm
WHERE toc.x = 400
GROUP BY toc.y
,tm.starts
) mt ON tmt.ord = mt.ord
AND tmt.starts = mt.starts
ORDER BY more_stuff

Code Blurg

When you are not really sure what you want, you can try it in more than one place! At the worst you get an additional line of code for your metrics.

insert #DeleteSpots

Select os.Linked_ID, os.BID

from #olspot ols

join dbo.ORDERED os on os.bid = ols.bid

AND os.B_Position IN(0,1,3)

where os.Linked_ID is not null

and os.B_Position = 3

Resolution notes are required for all fixes

This came from our crazed supervisor today ...

From now on, please make all resolution notes in Haiku form. By way of example:

Try it again please.
Whatever the problem was;
Works on my machine.

Why have all the commission rates gone?

I liked this one. This is what happens when you start cutting and pasting code without looking at the end result real close.

In this situation, the developer was removing a variable that had a default value of zero. Guess they figured that the safest thing to do was to replace it with that number. There were a couple of places in this 460 line procedure to change. They must have checked the top half which was just fine, but the original designer had basically copied the first 200 lines and duplicated them in the second half - and he did not use the variable the same way. The maintenance developer did not check this second half which ended up as below.

Snippet:

SELECT
round(convert(money,sum(r.rate) * 0),2)
,0
,round(convert(money,sum((r.rate * 0) * isnull(r.ag_com_pct,0))),2)
,count(*)
FROM
Whatever

The French know the secret to destroying database performance!

I saw this on GOOGLE VIDEOS and thought it was the funniest SQL performance technical explanation I had ever seen. His name is Stephane Faroult at RoughSea Ltd. It is also nice in that he turned the problem on its head and looked at the performance problem backwards. How to make it worse.

Who would have believed it

I was reading Aristotle and thinking how I could create a software development paradigm based on his nicomachean ethics. Then I ran into an LA Times blog about these guys and their radio program. I think it terribly interesting to see where this show airs - plus its a lot of fun to listen to. All the past shows are available for download.

"This is not a lecture or a college course, it's philosophy in action! Philosophy Talk is a fun opportunity to explore issues of importance to your audience in a thoughtful, friendly fashion, where thinking is encouraged".

http://www.philosophytalk.org/

A Shortage of ees

Well, now ush has really done it. Apparently gloal warming has een sighted in unexpected areas. Everody is talking aout the mysterious disappearance of ees. There are less and less of them and the ig question is why? I dont know why people get all worked up aout this kind of thing. Just get a new keyoard.

Origami

Nate tells me that he used to go to an origami class before the school folded.

609.5

From another conversation ...

"It reminds me of the handyman who caught a fish shaped like the letter L.

He, as it turns out, metacarple".

#604

One of the 1.3 million returned results from a google search of PINK LEMONADE will get you this ...

http://digg.com/videos/comedy/Horrific_Projectile_Vomit_Ensues_After_Drinking_Mysterious_Lemonade

In the old days, a 20MB harddrives setup as a fileshare would get loaded up with junk after a couple of months. It would be horribly disorganized where you couldn't find anything. No one would clean it out because they were afraid they would lose something important. Someone would finally just get another drive. Then the same thing would happen again.

Now its just more people messing it up. More harddrives. The internet should have some standards set that we all have to adhere to before it fills up with porn and puke.

Less is more

This is the story of a man named Jed
A poor programmer that had been hit in the head
Then one day he did a query for a home
Did a top one and ended in Oklahom (a)

Thing is, this guy correctly figured that for every address on a street, there was only one possible number. But there could be more than one person registered at a household and he really only wants one of them. So he does

SELECT TOP 1 FROM Adresses WHERE Street = @a and Address = @b

Thing he forgot about was that there might possibly be a 123 Main Street in more than one city. In a different state.
They're still digging themselves out of the huge data corruption that this created.

But but but

Another SQL 2000 failure that seems to be OK anywhere else you try it.

-- Do something
GOGO
-- Do other stuff

Why that isn't an error in 2005 is a little curious

Wait a minute

OK, Check this out. There are no errors in 2005 or 2008 even with that comma dangling off the end ...

CREATE TABLE [dbo].[AdvertiserSamCategory] (
[AdvertiserSAMID] [int] IDENTITY (1, 1) NOT NULL ,
[AdvertiserID] [INT] NOT NULL ,
[DomainLogin] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[SamCategoryID] [INT] NOT NULL ,
) ON [PRIMARY]

Guess you really don't need that definition

Where am I

Here is the Microsoft way to figure the version and servicepack levels

Declare @V varchar(10), @sp varchar(5), @ed varchar(32), @nm varchar(32)
SELECT @v=convert(varchar(10),SERVERPROPERTY('productversion'))
,@sp=convert(varchar(5),SERVERPROPERTY ('productlevel'))
,@ed=convert(varchar(32),SERVERPROPERTY ('edition'))
,@nm=convert(varchar(32),@@servername)
Print 'SERVER:' + @nm
Print 'Version ' + @v
Print 'Level ' + @sp
Print @ed

My local 2008 server for example produces the following:

SERVER:WEB-TESTMULE
Version 10.0.1049. <====Note the extra period! Level CTP Developer Edition

What's in a name?

IN everything but SQL2000 this is not a problem. Seems in 2000, the tableName does not get
an automatic name reference, such that the use of tableName.xxx results in a syntax error.


You must alias the table name even if it is the same name.


SELECT tableName.Col FROM tableName tableName

What was that name again?

In SQL 2005 this is OK


SELECT 1
FROM sysobjects (nolock) o
JOIN syscolumns (nolock) c ON o.id = c.id


But we build in SQL 2000 and it must be like this


SELECT 1
FROM sysobjects o (nolock)
JOIN syscolumns c (nolock) ON o.id = c.id


So unless you alias the table before the hint, you will get a syntax error in some cases.


Incorrect syntax near 'o'.

#27

Misfits converge.

... think about it ...

GO speedracer GO

PRINT 'Here is a test'
/*
Here is a place for a comment to
GO
*/


The commented GO statement within the /* */ still executes and as such will cause a syntax error. This is corrected in 2005 servers but you will have to watch out for it on current boxes.

Update August fifthe 2009
We got hit by this again so I did some further experiments. Turns out it is related to the OSQL/ISQLW/ISQL installed and not the server. You can run this same script from a machine with the 2005 tools installed and point to the 2000 server and there is no error.

Point is then, when you are testing for compatibility of your scripts, don't run it from the 2005 management studio. You will get a false positive.