Microsoft KB Archive/173844

From BetaArchive Wiki
< Microsoft KB Archive
Revision as of 10:07, 21 July 2020 by X010 (talk | contribs) (Text replacement - """ to """)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Knowledge Base


BUG: Dbsqlexec and Dbsqlok Return Code Documentation Is Incorrect

Article ID: 173844

Article Last Modified on 10/3/2003



APPLIES TO

  • Microsoft SQL Server 6.5 Standard Edition



This article was previously published under Q173844

SYMPTOMS

BUG #: 17186 (Windows: 6.5)

SQL Server Books Online says that the dbsqlexec and dbsqlok functions can return SUCCEED or FAIL. The functions can return either of these values; however, the FAIL is only a representation of the current command of the batch.

In most cases, the return code from dbsqlok or dbsqlexec should be ignored. If you send the following batch:

   insert into tblTest values(1)
   select @@VERSION
                

and the INSERT statement fails due to a duplicate key, a severity 14 error is generated but the batch continues. The dbsqlok and dbsqlexec calls only check the success of the first command. If you do not call dbresults, you will not process the SELECT statement results. In this case, you may get "result pending" errors.

WORKAROUND

To work around this problem, see the following article in the Microsoft Knowledge Base for complete result processing details:

165951 INF: Result Processing for SQL Server


In most cases, you will ignore the return code and continue the dbresults looping until either NO_MORE_RESULTS is returned or DBDEAD becomes TRUE. This ensures that all result sets are processed.

STATUS

Microsoft has confirmed this to be a problem in SQL Server version 6.5. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.


Additional query words: sev

Keywords: kbbug kbprogramming KB173844