views:

33

answers:

1

I have a legacy web-site that I am maintaining (built mostly in classic ASP with vbscript). I am making some modifications to it, and got tired of waiting 5 minutes everytime I had to go through one of the pages that was loading 99000 records from the database before displaying the first 20 of them, so I rewrote the code as:

sSQL = "WITH OrderedAgreements AS (SELECT *, ROW_NUMBER() OVER (ORDER BY " & strSort & ") AS 'RowNumber' FROM ServiceAgreement " & WhereClause & ")"
sSQL = sSQL & " SELECT * FROM OrderedAgreements WHERE RowNumber BETWEEN " & iStartRec & " AND " & iStartRec + iPageSize - 1
Set rs = Server.CreateObject("ADODB.Recordset")

rs.Open sSQL, SQLConn, adOpenStatic, adLockReadOnly

(the objective being to return only the rows that will actually be displayed).

This runs fine when run from IIS-7 on my local development machine (Windows 7). It is accessing a test database under SQL Server 2008 on a development server in an adjacent lab.

However, when I run the identical code in a beta site on the production server (i.e., a parallel directory tree to the production site, accessed through a different HTTP port), it gives me a "syntax error near keyword 'WITH'"

The production server is running Windows Server 2003 R2 and IIS 6, but I can't think of a reason why that should cause an error on one machine and not on the other. They are running identical code, connecting to the same database, accessed with the same sequence of command. I even put some logging code in to output the SQL that is being generated, and it is identical in both cases. Both machines are running the 2.0/3.0/3.5 framework. Both machines have SQL Server 2008 installed.

The production server is accessible to me (via RDP), but it does not have Visual Studio on it. I am pretty much at my wits end as to figuring out why the same code is getting an SQL syntax error on one machine and not the other.

Can anyone give me a clue as to how to proceed? Thanks.

+2  A: 

Options. in order of likelihood...

  • What is the DB compat level? sp_helpdb will show you. You need to be 90 or above to use a CTE

  • What does SELECT @@VERSION say on both SQL Servers? Really both '2008?

  • Try ;WITH... in case you have an extra SQL command before the CTE

An observation... why not use parameters rather the string concatenation?

gbn
Both sites are connecting to the same SQL Server, even though they each have SQL server installed. Neither is running on a DB on the machine - they are both connecting to the same remote development database. So I would assume that SELECT @@VERSION is going to return the same thing in both cases, since they're connecting to the same DB. And I assume the same for sp_helpdb, but I'll give it a try.I'll give the semi-colon a try, but since the sSQL string is starting out empty, I can's see how there could be a statement before it.
Dave Hanna
You have to check the remote SQL Server: this is where your SQL runs. Who cares what is installed locally? Also, do they connect to different databases with different compat levels? I would also check SELECT @@SERVERNAME to ensure all your SQL is running on the same box. The same SQL on the same DB on the same instance from different clients *will not* run differently.
gbn
Well, I'm not sure which it was - I changed the compatibilty level from 80 to 90 (hope that doesn't end up messing anything else up - I think it was just that way by default, since the DB was originally migrated from an older server), and I also added the semi-colon. It now works on the beta server. So I won't complain. Thanks for your help.
Dave Hanna
+1 for the "avoid string concatenation" ... you would think by now, with all the talk of SQL injection attacks, everyone would know to avoid this 100% of the time...
marc_s
@Dave Hanna: 80 is SQL Server 2000, 90 is SQL Server 2005. SQL Server 2000 did not support CTEs, thus causing this error
gbn