Fuck You, SQL Server

Today's SQL Server hate topic is ISNUMERIC.

SELECT ISNUMERIC('350000' + CHAR(160))

-----------
1

(1 row(s) affected)

SELECT CONVERT(INT, '350000' + CHAR(160))

-----------
Msg 245, Level 16, State 1, Line 1
Syntax error converting the varchar value '350000 ' to a column of data type int.

FUCK YOU.

(the solution is to convert to Money first, then Int, but really, FFS. I have no idea what unprintable character 160 is doing in the source file, but there's no accounting for our clients unfortunately.)

It's interesting that CHAR(160) = # for me. It's not a legal UTF-8 character, so if you're using UTF-8, it may provoke undefined behavior.

Nope, it's an ASCII field, not Unicode.

ASCII is defined for 0-127. Above that, you're in another character set. In ISO-8859-1 and ISO-8859-15, 160 is a non-breaking space, but I really have no idea what charset MS is pretending is "ASCII" between 128-255.

I assume that's why it's unprintable.

FUCK YOU FUCK YOU FUCK YOU.

Trying to edit an SSIS package because a client changed their XML spec, and I get this handy error every time I try to edit a component:

Error HRESULT E_FAIL has been returned from a call to a COM component.

Can't get any details about it at all.

Then my SQL Server Management Studio crashed when I tried to connect to Integration Services.

AND every time I try and add columns to a table using the Management Studio it times out, which SQL Server 2000 Enterprise Manager didn't do.

SQL Server 2005 really is a piece of fucking shit.

YOU FUCKING CUNTS

CREATE TABLE #Results
(SvrName VARCHAR(255)
,DBName VARCHAR(255)
,string VARCHAR(255)
,xtype VARCHAR(10)
,name VARCHAR(256))

IF @includeDetails = 1
BEGIN
ALTER TABLE #Results
ADD Details VARCHAR(4000)
END

Warning: The table '#Results' has been created but its maximum row size (9066) exceeds the maximum number of bytes per row (8060). INSERT or UPDATE of a row in this table will fail if the resulting row length exceeds 8060 bytes.

WTF??! 255 + 255 + 255 + 10 + 256 + 4000 is blatantly NOT more than 8060 you stupid piece of shit!

What are you running that code on? I run that on SQL2000 and get no error message.

SQL 2000, in a stored proc.

It works outside the proc.

I also get this:

Cannot sort a row of size 8106, which is greater than the allowable maximum of 8094.

when doing SELECT * FROM #Results

I'm not asking it to sort! WTF!

Is it implicitly turning it into an NVARCHAR for some stupid reason? I'm stumped.

I even added exec tempdb.dbo.sp_help #Results to the proc and got this:

SvrName varchar no 255
DBName varchar no 255
string varchar no 255
xtype varchar no 10
name varchar no 256
Details varchar no 4000

So it's definitely creating the temp table as I'd expect it. Where is it getting these figures of 9066 and 8106 bytes from??

Tried replacing the temp table with a permanent one, same thing. ???!!!

What Characterset are you using?

It's not that I've sort of fixed it now. It's a misleading/wrong error message - the problem had nothing to do with creating the table.

I was inserting data that was NVARCHAR into the table, that took it over 8060 bytes. Why it decided to tell me there was an error creating the table rather than inserting into it I have no idea. I added explicit CONVERT(VARCHAR(4000), <nvarchar field>) to the INSERT statement and the error went away (although I still get the warning message, which is annoying but not really a problem I suppose).

I miss SQL Server :(

ms sql server, the only database i've encountered able to deadlock on concurrent reads.

With (nolock), dudes..

^^^

I'm quite nostalgic about the complaints I had upthread. I'd give anything to swap annoying ISNUMERIC logic to the abject horror that is MySQL.

Luckily everyone who works here agrees with me and we're looking to move everything to Postgres but that will take a long time to happen.

ARGGGHHHHHH IJKOFJ034UF903RUFJE

just about ready to murder sql