views:

381

answers:

1

We are migrating ASP code that used ADO to connect to SQL Server 2000. For the most part the code migrated without a hitch to SQL Server 2008 after defining the connection, but one type of query is throwing an error that puzzles me.

Against SQL 2000, we would use code like this:

set oCommand = Server.CreateObject("ADODB.Command")
oCommand.ActiveConnection = oConn 'already established
oCommand.CommandType = adCmdText 

'This is simplified over the real code, but the wrapper is what we use.
oCommand.CommandText = "<Root xmlns:sql='urn:schemas-microsoft-com:xml-sql'><sql:query>" 
+ Server.HTMLEncode(sql) 
+ "</sql:query></Root>" 

oCommand.Dialect = "{5D531CB2-E6ED-11D2-B252-00C04F681B71}" 'SQL Dialect GUID
oCommand.Properties("Output Stream").Value = oXMLDoc 'Already created
oCommand.Execute , , adExecuteStream 'The point of error

The SQL is a stored procedure call that works when called normally. This code continues to work against SQL 2000, but against SQL 2008 it returns:

ERR_OPENSQLXML XMLDB.openSQLXML failed. Error '-2147217898': 'Command dialect is not supported by this provider.'

My first guess is that SQL 2008 relies on MSXML version 6, and I need a new guid. My MSDN and Google-Fu has failed me: all the results I find use this GUID.

Is there a new GUID? Is there a better way? Is that better way less hassle than recoding in ASP.NET (the fate of many pages already).

EDIT: I'm wondering if using the SQLNCLI10 client is preventing this from working?

configConnString = 
"Provider=SQLNCLI10;DataTypeCompatibility=80;Server=XYZZY;Database=ucpm;MARS Connection=True;Trusted_Connection=Yes;"
+1  A: 

Rather than focus on the language which i haven't seen documented as changed - ASP.dll is still supported in the next version of windows server from the last check i made.

Can you check the client you are connecting from has the MSSQL Native Client 10 installed rather than the old sql 2000 odbc/oledb clients.

u07ch
I have updated the question with the connection string used. I am using the SQLNCLI10 provider, which has been great with traditional parameterized queries, just not the XML stream.
Godeke
Two things apologize if the first is patronizing; has sqlxml been installed; in sql 2008 its not installed by default.http://msdn.microsoft.com/en-us/library/cc645615.aspxSecond; can you try the test sample ms provide in cscript to check that its all working as expected http://msdn.microsoft.com/en-us/library/ms171785.aspx
u07ch
And no, checking if it is installed wasn't patronizing. Very often it is the simple answer that is correct :)
Godeke
The test script pointed to works. I fed it the query that is failing in ASP/ADO and it worked like a champ, returning the XML document with the correct data. I note that the example doesn't use the DataTypeCompatibility=80 (which I thought was necessary for classic ASP/ADO connections to the native client).
Godeke
I have no idea on that; i know that DataTypeCompatibility 80 was to support sql2005 data types. All their other examples are using it though. If you have jumped from 2000 - > 2008 then you likely aren't using n/varchar(max) or the other new types so you can probably get away without it. I cant see anything on google that would explain why that would cause an error though.
u07ch
Opening a new connection to the database using a string of the nature "Provider=SQLXMLOLEDB.4.0;Data Provider=SQLNCLI10;Server=XYZZY;Database=ucpm;Integrated Security=SSPI" is working around the problem. As all the XML queries run through one utility function, opening this second connection is good enough. Thank you.
Godeke