Re: SQL Native Client 10 ODBC + " delimiter + ;1 results in 'Could not find stored procedure'

Tech-Archive recommends: Fix windows errors by optimizing your registry



What format other than the standard ODBC format should be used for making ODBC calls from an ODBC client that will work with any ODBC driver and ODBC compliant server should be used? This is no old outdated format. Its the _only_ accepted ODBC format according to Microsoft's own ODBC Grammar located in http://msdn.microsoft.com/en-us/library/ms710248(VS.85).aspx?ppud=4

Furthermore, I don't think it violates anything mentioned in http://msdn.microsoft.com/en-us/library/ms131685.aspx

Yes, I suppose its the "version number". If the version numbers were not supposed to be part of the name then the ODBC call to SQLProcedures shouldn't be returning them. Even more strongly supporting this, if I make a call to SQLProcedures passing in SchemaName dbo and ProcName of stproc, the catalog call returns back starting the procedure is named stproc;1.

Again, I am talking about using a generic ODBC tool which is making catalog calls to MSSQL to determine what procedures exist on the server and how to execute them. And because the call to SQLProcedures is returning back ;1 as part of the name, and ; requires a delimiter according to some spec (I forget if its ODBC, ISO, ANSI or someone else's) that means that the server should accept it.

Again, this isn't something that should need to be changed on my side unless I want to have to add work-arounds for SQL Native Client violating Microsoft's own specs. If SQLProcedures is returning back a procedure name of stproc;1 then I should be able to execute this using that within delimiters as that is what the server is telling me the procedure is named.

Also, the ;1 version has nothing to do with ODBC. Maybe you can say its something that MSSQL inherited from Sybase, but its not something in the ODBC standard.



Sylvain Lafontaine wrote:
Well, you are using here the (very) old canonical form for an ODBC call and there is so much you can do with these fossils from the past. I would have expected that if it work with the version 9 of the SQL-Server Native ODBC Provider, it would have also worked with the version 10; however, I'm not that much surprised to learn that it doesn't work anymore.

There is also a second problem and it has to do with the ;1 stuff. After reading your post a few times, I not sure if this ;1 is part of the name of your SP as defined on the SQL-Server or if it is a version number. The version number is another old ODBC thing to be used against some flavor of sql-server like the old VAX/VMS and I have no idea how this ODBC form will translate against SQL-Server. Furthermore, you have said at the beginning of your post that the SP was named dbo.stproc;1 but later, you said that you can call it by simply using dbo.stproc instead of dbo.stproc;1.

If this ;1 is a version number and is not part of the name of the SP as defined on the SQL-Server, then you should not put it between quotes because if you do this, this version will get sent to the SQL-Server instead of beeing stripped by the ODBC driver and this will make it unrecognisable by SQL-Server.

If the version is not part of the name, then it should not be enclosed between quotes but if it is then yes, it should be part of the quoted named. Furthermore, in the first case, I'm not really surprised that adding a version number inside an ODBC canonical call make it fails against SQL-Server when using the latest ODBC provider. You can call this a bug but there is so much you can do with these old things. If it works with the version 9, keep it this way but if you really need to make it work with the version 10; then probably that you'll have to start making change on your side.

.



Relevant Pages

  • Re: Linking tables access - sql server 2005
    ... You might check a SAP user group, ... using the older SQL-Serve ODBC Provider or if you are using the latest Native ODBC Provider for SQL-Server, either the version 9.0 (that comes ... versions of the native providers will work against other version of SQL-Server); see the Microsoft SQL Server 2008 Feature Pack to separately download the version 10 of the Native Provider for SQL-Server: ... Sylvain Lafontaine, ing. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Linking tables access - sql server 2005
    ... using the older SQL-Serve ODBC Provider or if you are using the latest ... the native providers will work against other version of SQL-Server); ... Sylvain Lafontaine, ing. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: SQL Native Client 10 ODBC + " delimiter + ;1 results in Could not find stored procedure
    ... expected that if it work with the version 9 of the SQL-Server Native ODBC ... it requires a delimiter if you are ... the object delimiter and it's called the QUOTED_IDENTIFIER setting. ...
    (microsoft.public.sqlserver.odbc)
  • Re: Linking tables access - sql server 2005
    ... sql native client 2005.90.4035.00 ... using the older SQL-Serve ODBC Provider or if you are using the latest ... SQL-Server); see the Microsoft SQL Server 2008 Feature Pack to separately ... Sylvain Lafontaine, ing. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: SQL Server 2005 vs. SQL Server 2000
    ... den SQL-Server 2005 untersucht. ... mit .NET-Applikation und ODBC ... Da fehlen noch Angaben wie welche .NET Version ... Welcher ODBC Treiber - alter SQL Server ...
    (microsoft.public.de.sqlserver)