VB6/SQL getting "Changed language setting to us_english" with one procedure

Hi.  
In an old VB6 application, I added a call to a new INSERT stored procedure that I created, for a table I also created.  I copied the formats from an existing one that works (and you can see them, attached as .sql files)

When VB6 executes the call to the proc, it returns two VB6 errors:  
VB6 error 5703, which shows as:
Error 01000: [Microsoft][SQL Server Native Client 10.0][SQL Server] Changed language setting to us_english.

Open in new window

VB6 error 5701:
Error 01000: [Microsoft][SQL Server Native Client 10.0][SQL Server]Changed database context to 'ProdDB'.

Open in new window

(I know that they are really not "errors" in SQL, but the existing VB6 code sees them as such.)

Even though I get this error back from my new procedure only, I have checked my user language settings, which point to English (picture attached).

Why would I get this behavior on only this one procedure?
I can post more source code if you want to see it.

Thanks!

LoginCREATE-TABLE.sql
CREATE-PROC.sql
Rob RudloffIT Development SpecialistAsked:
Who is Participating?
 
Rob RudloffIT Development SpecialistAuthor Commented:
Anthony Perkins --
SO, the "BEGIN / SAVE / COMMIT TRANSACTION" stuff is not needed?  (I've just been copying really old procedures from that DB as a template for new ones)

Jkaios --
I can't "USE ProdDB" at the top, because the procedures actually exist in two different databases with two different names, one "restored" from the other.  Then an ODBC connection points to a database selected by the user.

But -- I found the problem ...

In the Insert procedure, the line returning the identity was:
     SELECT CCARD_TRANS_ID = @@IDENTITY
but should be:
     SELECT @CCARD_TRANS_ID = @@IDENTITY

Strangely enough, fixing that makes it so those two SQL "informational" messages don't pass back to VB, and thus the 5701 and 5703 messages in VB6 go away.

-- Thanks all.
0
 
jkaiosIT DirectorCommented:
try inserting the keyword "USE [database]" at the very top of each SQL script as follows:

   USE ProdDB

   Create procedure...
0
 
jkaiosIT DirectorCommented:
...oh and according to some MSDN blog:

Applications can simply ignore these 5701 and 5703 messages, they are purely informational.

http://blogs.msdn.com/b/developingfordynamicsgp/archive/2009/08/12/what-are-errors-5701-and-5703-that-show-in-the-dexsql-log.aspx
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
Anthony PerkinsCommented:
I know that they are really not "errors" in SQL, but the existing VB6 code sees them as such.
Could you elaborate by posting your code so that we can see how VB6 sees those errors.

]Unrelated to your question, but the Transaction is not needed and you may be better off using SET NOCOUNT ON at the top of your Stored Procedure.
0
 
Anthony PerkinsCommented:
SO, the "BEGIN / SAVE / COMMIT TRANSACTION" stuff is not needed?
SQL statements are Atomic.  They either succeed or fail.  So in your specific case there is no need to wrap a single INSERT statement in a Transaction.
0
 
Rob RudloffIT Development SpecialistAuthor Commented:
The actual error was a typo in my original SQL procedure, as described above.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.