Login | Sign Up
ErrorKey - Search engine for Error codes and messages     
  SQL Server  [ 1000 result(s) ]
CISCO IOS IBM IBM DB2 MICROSOFT ORACLE SAP SYBASE SQL Server 
00D3111F  -  IBM DB2
The maximum amount of buffered query data has been exceeded. Rather than return one block of query data, the DRDA server system elected to return multiple extra blocks. Instead of fetching all rows in all the extra blocks, the requesting application executed an SQL statement not related to the query or executed a commit while a held cursor was still open. DB2 buffers the extra in-transit blocks, however DB2 was not able to buffer the entire set of extra blocks and thus truncated the result set. The application then resumed fetching and attempted to fetch data beyond the point of truncation. ; The SQL statement fails.
Notify the system programmer. ; Notify the system programmer. ; Determine the failing application program and consider the following resolutions: v The cursor definition may cause the server to return extra blocks. In this case, the cursor definition can be changed to reduce the number of rows, thus extra blocks, being returned by the server. DB2 UDB for z/OS systems return extra blocks for cursors defined with the Optimize For n Rows clause and will return only enough extra blocks in order to return n rows. When a cursor is defined with Optimize For n Rows, either in the application or in a stored procedure, this indicates an application intent to fetch all n rows before attempting to execute other SQL statements. The application is not abiding by its intent and is executing other SQL, or committing, prior to fetching all n rows. In this case, the cursor definition can be changed to reduce the value of n, or the application logic can be modified to fetch all n rows or to close the cu
Comments
 
00D30103  -  IBM DB2
This reason code may be returned for a failed distributed commit using DRDA protocols. It indicates that commit has failed because an ABNUOWRM reply message was received from the server for a prior SQL statement, but an abort had not been driven at the DB2 requester prior to this commit and after the receipt of the ABNUOWRM. An ABNUOWRM reply message is sent by the server when it has rolled back its unit-of-work in response to an unusual situation at the server (for example, deadlock or operator intervention). When an ABNUOWRM reply message is received by the requester, an abort must be driven at the requester to synchronize the distributed systems. Until an abort is driven, all subsequent SQL statements will receive an SQLCODE -906. After an abort is driven, further SQL statements will be accepted. This reason code is issued by the following CSECT: DSNLCMT1 ; The commit at the DB2 requester fails.
Scan backwards in your application for the first non -906 SQLCODE prior to the commit. This SQLCODE was returned with the ABNUOWRM from the server system. Use the server product reference manuals to determine and correct whatever problem this SQLCODE represents on the server and rerun your application. This may involve contacting your system programmer if the situation at the Server cannot be corrected or improved by changes to the application program. ; The operator will not detect this problem. ; Determine the cause of the problem represented by the SQLCODE returned with the ABNUOWRM and if necessary, work with the system programmer at the server to resolve it. If you suspect an error in DB2, refer to Part 2 of DB2 Diagnosis Guide and Reference for information on identifying and reporting the problem. ; Collect the following diagnostic items: 928 Messages and Codes v User’s application output, including SQLCAs returned for each SQL statement.
Comments
 
00D35030  -  IBM DB2
DB2, acting as a DRDA server, detected an error while processing an SQL request from a remote DRDA client. DB2 was building a DDM query descriptor (QRYDSC or FDODSC) to return to the DRDA client, but could not do so because the descriptor required more late environment descriptors (LEDs) than DB2 can support. ; The DBAA is abended. The conversation with the remote site is terminated. At the server console, the DSNL027I message is issued, accompanied by one or more DSNL028I messages identifying all remote sites where the distributed agent also exists and where diagnostic information might also be collected.
The SQL request issued by the client cannot be processed by DB2. As a circumvention, the SQL request can be simplified to reduce the number of LEDs required to describe the data using DRDA. LEDs may be required, for example, if columns being fetched are in a different code page (CCSID) than the default CCSID for the DB2 for MVS system. ; Notify the application programmer or user creating the SQL statement. If the remote DRDA client is a DB2 for MVS system, collect the following diagnostic items listed in Appendix C, “Problem determination,” on page 1353: 83. For other remote DRDA clients, refer to the client product documentation for diagnostic recommendations. At DB2 DRDA server, collect the following diagnostic items listed in Appendix C, “Problem determination,” on page 1353: 1, 49. This abend reason code is issued by the following CSECT: DSNLZSRD.
Comments
 
00D30106  -  IBM DB2
The result of a DRDA distributed commit could not be determined because the reply message from the server either was invalid or could not be deciphered. This reason code is issued by the following CSECT: DSNLCMT1 ; An alert is generated and sent to NetView. An IFCID 0191 trace record may be written to the statistics class 4 trace, and a DSNL031I message may be written to the console. The trace record and Chapter 40. X’D3......’ codes 929 message will not be written if this error was previously detected within the last 5 minutes. The statistics class 4 trace must be active for the trace records to be written. The requester disconnects from the server system. The state of the unit of work at the server is unknown. It may have been committed, or it may have been rolled back. An SQLCA indicating the nature of the DRDA reply message distortion is given to the application.
Notify the system programmer. After the problem has been resolved, re-connect to the server site to determine whether the last unit of work was committed or rolled back. Continue your application after correcting the server database (if necessary). ; Notify the system programmer whenever a DSNL031I message is written to the MVS console. ; This is a DRDA distributed protocol problem. Once the nature of the problem is known, the server system programmer may have to be contacted to help resolve the problem. If you suspect an error in DB2, refer to Part 2 of DB2 Diagnosis Guide and Reference for information on identifying and reporting the problem. ; Collect the following diagnostic items: v Listing of the user’s application program output, including printouts of the SQLCAs received for all SQL statements. v Console output from the system on which the job was run, and a listing of SYSLOG data set for the period of time spanning the failure. v Listing of the statistics class 4 trace recor
Comments
 
00D3010B  -  IBM DB2
Cached information was used to determine whether updates are allowed at the server. From the time of the execution of the CONNECT statement to the time that the first SQL statement was sent to the server, the conversation SYNC_LEVEL supported by the partner changed from a cached value of SYNC to the current of value NONE. SYNC_LEVEL NONE servers are not allowed to update in the current unit of work. Since an update might have been performed by the partner during execution of the first statement at the server, the application must roll back (abort). This reason code is returned as a token in the SQLCODE -904. This reason code is issued by the following CSECT: DSNLTAC1 ; The connection to the server is deallocated. The server’s portion of the current unit of work is rolled back at the server. The application is placed in a must-abort state. All subsequent operations except rollback or abort fail with an SQLCODE -918. The remainder of the current unit of work is backed out when rollback o
If your application does not do any work at a server for a long time after issuing a CONNECT, consider rewriting it to perform the CONNECT immediately before performing any work at the server. This minimizes the possibility of the server system going down and coming back up at a different SYNC_LEVEL. Rerun your application starting with the unit of work containing the SQL statement that received an SQLCODE -904.
Comments
 
00D3010C  -  IBM DB2
Cached information was used to determine whether updates are allowed at the server. From the time of the execution of the CONNECT statement to the time that the first SQL statement was sent to the server, the partner was started with a program that does not support two-phase commit. Such servers are not allowed to update in the current unit of work. Since an update might have been performed by the partner during execution of the first statement at the server, the application must roll back. This reason code is returned as a token in the SQLCODE -904. This reason code is issued by the following CSECT: DSNLTAC1 ; The connection to the server is deallocated. The server’s portion of the current unit of work is rolled back at the server. The application is placed in a must-abort state. All subsequent operations except rollback or abort fail with an SQLCODE -918. The remainder of the current unit of work is backed out when rollback or abort is performed or when the application terminates.
If your application does not do any work at a server for a long time after issuing a CONNECT, consider rewriting it to perform the CONNECT immediately before performing any work at the server. This minimizes the possibility of the server system going down and coming back up at a different level. Rerun your application starting with the unit of work containing the SQL statement that received the SQLCODE -904.
Comments
 
00D300F6  -  IBM DB2
A valid but unexpected DDM reply was received from a remote server during a connect, commit, or abort operation. For a connect, the expected DDM reply is EXCSATRD (for EXCSAT command) or ACCRDBRM (for ACCRDB command). For a commit or abort, the expected DDM reply is ENDUOWRM. (The DDM command for a commit is RDBCMM. For a rollback, it is RDBRLLBCK). This reason code is issued by the following CSECTs: DSNLBABR DSNLCMT1 DSNLTAC1 DSNLTEX1 ; The local DB2 tried to access a remote server and the server replied with an unexpected DDM answer. The remote server may have suffered permanent damage. The local DB2 may or may not subsequently disconnect the conversation to the server. This is an internal-only DDF reason code. The local DB2 requests neither a SVC dump nor a SYS1.LOGREC record.
Contact the system programmer ; If the SQLCA is available, examine all fields in the SQLCA. Using this information, try to determine what DDM reply was received. Contact the system programmer at the server site with this information. This is probably a programming error at the server database system, although it may be a DB2 error. The server database system may have recorded diagnostic information for the problem. If this is a DB2 error, write an APAR. ; Examine the SQL return code in the SQLCA. It should give further indication of the real cause.
Comments
 
00E70110  -  IBM DB2
The commit failed because the application was not connected to the Current Server. This abend reason code is issued by the following CSECT: DSNXECW ; The reason code or SQLCODE -900 is returned to the application which is in an unconnected state. User Response: A previous failure has left your application in an unconnected state . Notify the system programmer that a system failure occurred during execution of your application. Any changes made in the last unit of work is rolled back. Re-run your application after determining the state of the Current Server database.
For Communication failure, refer to DSNL500I message. Diagnose the failure that left the user application in an unconnected state. See “Problem Determination” section below. Refer to the previous SQL error in the application.
Comments
 
00D3104A  -  IBM DB2
A remote server issued an SNA BACKOUT, which was not sent as a reply to an SNA PREPARE or REQUEST_COMMIT. This indicates the server backed out the current unit of work without waiting for the SQL application to either commit or roll back. This abend reason code is issued by the following CSECT: DSNLVRPL ; The attempt to access the remote database resource fails and the failure is reported to the application. DB2 terminates the SNA conversation to the remote server and forces the application to roll back.
Notify the DB2 systems programmer. ; DB2 never issues an unsolicited SNA BACKOUT. Non-DB2 servers can send an SNA BACKOUT indication when resources required to complete the unit of work are not available. For example, a deadlock might cause the non-DB2 server to send an SNA BACKOUT. Contact the system programmer for the remote system to determine why 944 Messages and Codes the unit of work had to be aborted. ; Collect the following diagnostic items listed in Appendix C, “Problem determination,” on page 1353: 1.
Comments
 
00D351FF  -  IBM DB2
DB2 received a DDM reply message from the remote server in response to a DDM command. The reply message, while valid for the DDM command, indicates that the DDM command and hence the SQL statement was not successfully processed. The application is notified of the failure through the architected SQLCODE (-300xx) and associated SQLSTATE. This reason code is issued by the following CSECT: DSNLZRPA ; An alert is generated and message DSNL031I is written to the console. Refer to the description of this message for further information.
Notify the system programmer. If you suspect an error in DB2, refer to Part 2 of DB2 Diagnosis Guide and Reference for information on identifying and reporting the problem. The statistics class 4 trace record identified by the IFCID sequence number included in the DSNL031I message should be analyzed. Collect the following diagnostic items at this local DB2. v Statistics class 4 trace record identified by the IFCID sequence number specified in message DSNL031I. Collect the following diagnostic items at the remote server. v Relevant error and system logs spanning the time of the failure. v Any relevant remote server trace information or dumps.
Comments
 
 

 
SQL Server Analysis Services (SSAS) (10)
SQL Server Enterprise Manager Error Messages (125)
INFORMIX (33)
SQL Server System Error Messages  (295)
SQL Server Embedded SQL for C Error Messages (ESQL/C)  (48)
C# .Net Compiler Errors and Warnings (1)
Crystal Reports Print Engine (1)
SQL Server DB-Library Error Messages  (19)
SQL Server Integration Services (SSIS) (151)
SQL Server Reporting Services (SSRS) (29)
Cisco IOS (1)
SQL Server Distributed Queries Error Messages  (1)
 
  Prev   1  2  Next