Error Guide

Open Client Error Messages Guide
Open Client 10.x and 11.x Document ID: 35217-01-1100-03 Last Revised: June 28, 1999
Principal author: Hema Seshadri, Contributing editors: Cris Gutierrez, Robin McCann, Jon Egerton-Kemp, Craig Sandvik, David Peterson Document ID: 35217-01-1100 This publication pertains to Open Client 10.x and 11.x of the Sybase database management software and to any subsequent version until otherwise indicated in new editions or technical notes. Information in this document is subject to change without notice. The software described herein is furnished under a license agreement, and it may be used or copied only in accordance with the terms of that agreement.
Document Orders
To order additional documents, U.S. and Canadian customers should call Customer Fulllment at (800) 685-8225, fax (617) 229-9845. Customers in other countries with a U.S. license agreement may contact Customer Fulllment via the above fax number. All other international customers should contact their Sybase subsidiary or local distributor. Upgrades are provided only at regularly scheduled software release dates. Copyright 19891999 by Sybase, Inc. All rights reserved. No part of this publication may be reproduced, transmitted, or translated in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without the prior written permission of Sybase, Inc.
Sybase Trademarks
Sybase, the SYBASE logo, Adaptive Server, APT-FORMS, Certied SYBASE Professional, the Certied SYBASE Professional logo, Column Design, ComponentPack, Data Workbench, First Impression, InfoMaker, ObjectCycle, PowerBuilder, PowerDesigner, Powersoft, Replication Server, S-Designor, SQL Advantage, SQL Debug, SQL SMART, Transact-SQL, Visual Components, VisualWriter, and VQL are registered trademarks of Sybase, Inc. Adaptable Windowing Environment, Adaptive Component Architecture, Adaptive Server Enterprise Monitor, Adaptive Warehouse, ADA Workbench, AnswerBase, Application Manager, AppModeler, APT-Build, APT-Edit, APTExecute, APT-Library, APT-Translator, APT Workbench, Backup Server, BayCam, Bit-Wise, ClearConnect, Client-Library, Client Services, CodeBank, Connection Manager, DataArchitect, Database Analyzer, DataExpress, Data Pipeline, DataServer, DataWindow, DB-Library, dbQueue, Developers Workbench, DirectConnect, Distribution Agent, Distribution Director, Embedded SQL, EMS, Enterprise Application Server, Enterprise Application Studio, Enterprise Client/Server, EnterpriseConnect, Enterprise Data Studio, Enterprise Manager, Enterprise SQL Server Manager, Enterprise Work Architecture, Enterprise Work Designer, Enterprise Work Modeler, EWA, Formula One, Gateway Manager, GeoPoint, ImpactNow, InformationConnect, InstaHelp, InternetBuilder, iScript,
Jaguar CTS, jConnect for JDBC, KnowledgeBase, Logical Memory Manager, MainframeConnect, Maintenance Express, MAP, MDI Access Server, MDI Database Gateway, media.splash, MetaBridge, MetaWorks, MethodSet, MySupport, Net-Gateway, NetImpact, Net-Library, Next Generation Learning, ObjectConnect, OmniConnect, OmniSQL Access Module, OmniSQL Toolkit, Open Client, Open ClientConnect, Open Client/Server, Open Client/Server Interfaces, Open Gateway, Open Server, Open ServerConnect, Open Solutions, Optima++, PB-Gen, PC APT-Execute, PC DB-Net, PC Net Library, Power++, Power AMC, PowerBuilt, PowerBuilt with PowerBuilder, PowerDynamo, PowerJ, PowerScript, PowerSite, PowerSocket, Powersoft Portfolio, PowerStudio, Power Through Knowledge, PowerWare Desktop, PowerWare Enterprise, ProcessAnalyst, Replication Agent, Replication Driver, Replication Server Manager, ReportExecute, Report Workbench, Resource Manager, RW-DisplayLib, RW-Library, SAFE, SDF, Secure SQL Server, Secure SQL Toolset, Security Guardian, SKILS, smart.partners, smart.parts, smart.script, SQL Code Checker, SQL Edit, SQL Edit/TPU, SQL Modeler, SQL Remote, SQL Server, SQL Server/CFT, SQL Server/DBM, SQL Server Manager, SQL Server SNMP SubAgent, SQL Station, SQL Toolset, Sybase Central, Sybase Client/Server Interfaces, Sybase Development Framework, Sybase Financial Server, Sybase Gateways, Sybase Learning Connection, Sybase MPP, Sybase SQL Desktop, Sybase SQL Lifecycle, Sybase SQL Workgroup, Sybase Synergy Program, Sybase Virtual Server Architecture, Sybase User Workbench, SybaseWare, SyberAssist, SyBooks, System 10, System 11, the System XI logo, SystemTools, Tabular Data Stream, The Enterprise Client/Server Company, The Extensible Software Platform, The Future Is Wide Open, The Learning Connection, The Model for Client/Server Solutions, The Online Information Center, Translation Toolkit, Turning Imagination Into Reality, UltraLite, UNIBOM, Unilib, Uninull, Unisep, Unistring, URK Runtime Kit for UniCode, Viewer, VisualSpeller, VisualWriter, WarehouseArchitect, Warehouse Studio, Warehouse WORKS, Watcom, Watcom SQL, Watcom SQL Server, Web.PB, Web.SQL, WebSights, WebViewer, WorkGroup SQL Server, XA-Library, XAServer, and XP Server are trademarks of Sybase, Inc. 2/99 Unicode and the Unicode Logo are registered trademarks of Unicode, Inc. All other company and product names used herein may be trademarks or registered trademarks of their respective companies.
Restricted Rights
Use, duplication, or disclosure by the government is subject to the restrictions set forth in subparagraph (c)(1)(ii) of DFARS 52.227-7013 for the DOD and as set forth in FAR 52.227-19(a)-(d) for civilian agencies. Sybase, Inc., 6475 Christie Avenue, Emeryville, CA 94608.
Table of Contents
How to Find Error Information 1. BCP and Bulk Library Errors Messages
Memory allocation failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Front end does not support this feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 Bulk login property must be set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6 Unknown datatype encountered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8 Conversion stopped due to syntax error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10 Unknown version of bcp format-le. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13 Unexpected EOF encountered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14 Oversized row/overow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15 Unrecognized datatype found in format le. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17 blk_init failed, or, Error occurred when attempting to localize . . . . . . . . . . . . . . . 1-18 Bulk alloc failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20 Identity columns and -E option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22 Missing external conguration data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
2. Embedded SQL/C and COBOL Error Messages

Unable to nd WHENEVER... statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 INCLUDE SQLDA not valid in ESQL/COBOL . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 Incorrect type of indicator variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5 Unrecoverable error occurred. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6 Unexpected CS_PARAM_RESULT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 Unexpected CS_ROW_RESULT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10 Incomplete result set processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12 Error initializing Client Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14 Server does not support TEXT or IMAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16 Unterminated C string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18 Invalid column name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19 Unchained transaction mode only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21 Invalid precision or scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
3. Client Library Error Messages

Call to connect two endpoints failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Title for Your Books Footers
Product Name & Version Number
Attempt to connect to the server failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7 Maximum number of connections already opened . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 Net-lib operation terminated due to disconnect. . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10 Routine cannot be called while results are pending . . . . . . . . . . . . . . . . . . . . . . . . 3-12 Command structure has results pending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 Illegal value CS_DATAFMT structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15 Parameter must be 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17 Illegal value for parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19 Server does not support parameters of type text/image . . . . . . . . . . . . . . . . . . . . . 3-23 No driver of the requested protocol class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25 Data NULL when dening input parameters for cursors . . . . . . . . . . . . . . . . . . . 3-27 Passing parameters by name and position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30 Bind resulted in truncation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32 Read from the server has timed out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34 Connection has been marked dead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37 CS_IODESC only for text or image columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38 CS_IODESC cannot be retrieved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40 CS_IODESC structure must be set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42 Bytes exceeds the amount specied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44 Bytes specied have not been sent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46 ID already exists on connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48 ID does not exist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53 Sticky binds do not match result set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-54 Error while binding to directory service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56 Attempt to load protocol driver failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-59
4. DB-Library Error Messages

SQL Server connection timed out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 Read from SQL Server failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4 Unable to open socket. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6 SQL Server is unavailable or does not exist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9 Maximum dbprocesses already allocated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12 Unexpected EOF from SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14 General SQL Server error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17 Results pending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19 Bad token from SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24 Unknown bind type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
vi
Table of Contents
Unknown datatype encountered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attempt to bind to a non-existent column. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . dbbind() with mismatched column and variable types . . . . . . . . . . . . . . . . . . . . . Attempt to retrieve data from a non-existent row . . . . . . . . . . . . . . . . . . . . . . . . . DBPROCESS is dead or not enabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Syntax error in source eld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unknown network type found in interface le . . . . . . . . . . . . . . . . . . . . . . . . . . . Too much TEXT data via the bcp_moretext() call . . . . . . . . . . . . . . . . . . . . . . . . . dbreadtext() may only be used to receive the results... . . . . . . . . . . . . . . . . . . . . . . Zero length TEXT or IMAGE to dataserver via dbwritetext() . . . . . . . . . . . . . . . DBPROCESS is being used for another transaction. . . . . . . . . . . . . . . . . . . . . . . Called dbmoretext with a bad size parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet size of %1! not supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Function can be called only once . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RPC parameters cannot be of type Text/Image . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-28 4-30 4-32 4-33 4-35 4-37 4-39 4-41 4-43 4-45 4-47 4-49 4-51 4-53 4-55
A. Commands to Find Sybase Versions B. Open Client/Server 10.0.x and 11.x Runtime Environment C. How to Interpret Client-Library Error SQLCODEs D. Sample Code for Error Handling E. Sample Code for Handling Large Text and Image Data
Title for Your Books Footers
vii
viii
Table of Contents
How to Find Error Information

How to Use This Book
This manual is intended to help you troubleshoot error messages from the following products: bcp utility and Bulk Library Open Client Embedded SQL/C and Embedded SQL/COBOL Open Client Client-Library
Which Errors Are Documented?

The errors documented in this manual are those that most frequently result in Technical Support calls. The manual is intended to help you resolve the most common problems yourself. However, you may experience errors which are not documented here.
How Do I Locate the Error Message I Need?

The Open Client products do not use a consistent error number system. Therefore, error numbers are not used as headings for sections on individual errors; instead, the headings are abbreviated from the message text. The best way to nd your error is to search for a string from the error message that you received. When searching for a string, try to leave out details that refer to the specic instance of the error; those details would be represented by placeholders in this document. For example, the following error message:
ct_param(): user api layer: external error: An illegal value of 0 was placed in the status field of the CS_DATAFMT structure.
is represented in this manual as:

ct_param(): user api layer: external error: An illegal value of %1! was placed in the %2! field of the CS_DATAFMT structure.
See Search Help in Technical Library for types of searches that might be most efcient.
ix
Open Client 10.x and 11.x
Related Documents
See the following manuals for more information on Open Client products: Open Client Client-Library/C Programmers Guide Open Client Client-Library/C Reference Manual Open Client and Open Server Common Libraries Reference Manual Open Client DB-Library/C Reference Manual Open Client Embedded SQL/C Programmers Manual Open Client Embedded SQL/COBOL Programmers Manual Open Client/Server Conguration Guide for your platform Open Client/Server Programmers Supplement for your platform Utility Programs for your platform
Sample Programs
This book contains sample code to help you resolve specic problems. You can nd additional sample programs by going to the Technical Documents collection of Technical Library on the Web at http://support.sybase.com. From the Support Services tab, select the link to Technical Documents. Search the collection for these TechNote titles: Client-Library Sample Programs Embedded SQL/C Sample Programs Embedded SQL/COBOL Sample Programs The TechNotes explain how to locate and download the samples.
Other Sources of Information

Use the Sybase Technical Library CD and the Technical Library Web site to learn more about your product: Technical Library CD contains product manuals and technical documents and is included with your software. The DynaText browser (included on the Technical Library CD) allows you to access technical information about your product in an easy-touse format.
Refer to the Technical Library Installation Guide in your documentation package for instructions on installing and starting Technical Library. Technical Library Web site includes the Product Manuals site, which is an HTML version of the Technical Library CD that you can access using a standard Web browser. In addition, youll nd links to the Technical Documents Web site (formerly known as Technical Information Library), the Solved Cases page, and Sybase/Powersoft newsgroups. To access the Technical Library Web site, go to support.sybase.com, click the Electronic Support Services tab, and select a link under the Technical Library heading.
If You Need Help

Each Sybase installation that has purchased a support contract has one or more designated people who are authorized to contact Sybase Technical Support. If you cannot resolve a problem using the manuals or online help, please have the designated person contact Sybase Technical Support or the Sybase subsidiary in your area.
xi
xii
BCP and Bulk Library Errors Messages
1.
This chapter includes some of the more common error messages returned by the bcp utility and by Bulk Library, a set of commands for performing bulk copying from Open Client applications. Error numbers may vary or may not be displayed depending on whether you are using bcp or Bulk Library. Therefore, error numbers are not always listed in this chapter.
Page -1
Memory allocation failed

Error Number None Message Text Open Client 11.x
Fatal error: memory allocation failed.
Open Client 10.0.x

Unable to allocate sufficient memory
Possible Cause This error can occur when there is insufcient memory on the host machine to perform the requested bcp operation. The amount of memory needed by bcp depends on the table denition, including the number of columns in the table, the number of text or image columns, batch size, and so on. Action To resolve the problem, take the following actions as appropriate: Check the amount of memory currently available to bcp on your machine. Increase physical or virtual memory, or exit other applications to free up resources. To check memory resources, use one of the following methods: UNIX Several UNIX commands can give you total and available memory information. Examples of UNIX commands that you can use include: dmesg top hpglance (HP only) See your operating system documentation for commands specic to your platform.
Page -2
Windows NT Check memory statistics as follows: 1. Start up the task manager. 2. Click on the performance tab. The box in the lower left corner of the performance display contains kernel memory information, including total, paged, and non-paged memory. If your bcp batch size is large, try setting it to a smaller size. Versions in Which This Error Is Raised bcp 10.0.x and 11.x Bulk Library 10.0.x and 11.x.
Page -3
Front end does not support this feature

Error Number 4805 Message Text
The front end tool you are using does not support the feature of bulk insert from host, please use the proper tools for this command.
Possible Cause Possible causes for this error include: The DB-library program initiating the bulk copy operation does not have the bulk copy property set. The bulk copy property was set after the connection was opened. See Error 4805 in the Adaptive Server(TM) Enterprise Troubleshooting and Error Messages guide for other reasons for the error. Action The call to enable bulk copy in a DB-library program must be made before you open a connection with dbopen(). Make the following DBLibrary call to enable bulk copy for a connection:
BCP_SETL(login, true); .... LOGINREC *login; DBPROCESS *dbproc; .... /* Establish a login rec */ login = dblogin(); .... /* Enable bulk copy for this loginrec */ BCP_SETL(login, TRUE); .... /* Establish a connection with the dataserver */ dbproc = dbopen(login, NULL); .... /* Begin bulk copy operations */ bcp_init ( .. ); ....
Page -4
Versions in Which This Error Is Raised This error is raised by Adaptive Server and SQL Server(R). and returned to DB-Library 10.0.x and later.
Page -5
Bulk login property must be set

Error Number 22 Message Text
Application must log in with bulk login property set.
Possible Cause This error occurs when a Client-Library application attempts to make Bulk Library calls without rst enabling bulk copy. Action By default the CS_BULK_LOGIN property, which enables an application to make Bulk Library calls, is set to false (CS_FALSE). An application enables bulk copy by setting the CS_BULK_LOGIN property to CS_TRUE. You can set the property to true in two ways: In the ct_con_props routine. Your application must call ct_con_props before calling ct_connect to establish the connection. You can set the bulk login property to CS_TRUE in this routine, for example like this:
CS_BOOL bool; .... bool = CS_TRUE; retcode = ct_con_props( *conn_ptr, CS_SET, CS_BULK_LOGIN, &bool, CS_UNUSED, NULL); ....
In a runtime conguration le. This is a new feature available with Open Client 11.x. Check to see if a runtime conguration le exists. The usual le name is ocs.cfg, but any name can be used and referenced within the application. If the le exists, check to see if it has a line setting the bulk login to FALSE. Edit the line or enter a new line to set the property to TRUE as follows:
CS_BULK_LOGIN=CS_TRUE
If no le exists and you wish to create one, use the le sample.cfg as a template. On Microsoft Windows platforms, the sample.cfg le is located in the ini subdirectory of the Open Client installation. On UNIX platforms, you can nd a sample.cfg le in the cong subdirectory.
Page -6
Note Creating an external conguration le named ocs.cfg can affect ClientLibrary based utilities such as bcp and isql. Unless you are completely familiar with the use and naming of the conguration le, we recommend setting the bulk login property in the application in the ct_con_props call.
Additional Information See the Open Client Reference Manual for more information about setting properties with ct_con_props and the conguration le. Versions in Which This Error Is Raised Bulk Library 10.0.x and later
Page -7
Unknown datatype encountered

Error Number 20060 Message Text Bulk Library
Unknown datatype encountered.
bcp
Unknown fixed-length datatype encountered. Note The rst error text is displayed only by the DB-Library programming interface (API). The error number is displayed only by the DB-Library programming interface.
Possible Cause DB-Library 4.x and bcp 4.x do not support numeric and decimal datatypes. Support for these datatypes was introduced in Release 10.x. If you get this error while using the bcp utility, you may be using a 4.x version of bcp with a 10.x or higher version of the Server. This error can occur with DB-Library 10.x and 11.x, as well as 4.x. DBLibrary defaults to 4.x behavior unless you explicitly instruct it to use 10.x or higher behavior. Action Take one of the following actions to correct the problem: If you are using bcp, upgrade to bcp 10.0.x or 11.x. The bcp utility is bundled with your Adaptive Server, SQL Server, and Open Client software. See Appendix A, Commands to Find Sybase Versions for the command for your platform to determine the version of bcp that you are currently running. If you are using DB-Library 4.x and wish to use the numeric or decimal datatypes, upgrade your Open Client product to the current release. See Appendix A, Commands to Find Sybase
Page -8
Versions for the command for your platform to determine the version of DB-Library that you are currently running. If you are using DB-Library 10.0.x or 11.x, include the following line of code in your DB-Library program:
dbsetversion(DBVERSION_100);
This call must be made before calling any other DB-Library routine, with the exception of dbinit. See the DB-Library Reference Manual page for dbsetversion for more details. Versions in Which This Error Is Raised bcp 4.x DB-Library 10.x and later.
Page -9
Conversion stopped due to syntax error

Error Number 26 Message Text bcp
The conversion/operation was stopped due to a syntax error in the source field.
Bulk Library
The conversion/operation was stopped due to a syntax error in the source field. Failed in conversion routine - syntax error.
Possible Cause When copying data in ascii format from a bcp or Bulk Library le to a destination table, bcp automatically converts the data to the corresponding column type in the destination table. This automatic conversion may fail for one of the following reasons: There is a mismatch between the data in the host le and its corresponding column datatype. For example, bcp cannot copy a value of 100 into a datetime column. See the conversion table in the Adaptive Server Enterprise Reference Manual for a list of conversions that the Server can do implicitly. The data in the host le does not match the format le denition. This is especially true of xed length records, where a single character out of place can cause problems. Characters embedded in the data, such as commas in numerical data, are not valid for the column type. For example, if bcp tries to copy a number written as 1,234,567 into an int, oat, numeric or decimal column, it raises a syntax error. Similarly, a currency symbol such as $ will cause a problem in an int, oat, numeric or decimal column. The characters used to specify column or row delimiters are embedded in the data. For example, a hyphenated word may cause a problem if you have dened the column delimiter as a hyphen.
Page -10
The host le contains fewer columns than the target table. If this is the case, the missing columns must allow nulls or have defaults. If they allow nulls or defaults, you need to enter a placeholder in the host le, separated by column delimiters. For example, if a table is dened as:
col1 int col2 int null col3 int
the host le does not contain any data for column 2, and the delimiter is a comma, the row in the host le should look like this:
100,,200
The hostle contains more columns than the target table, and you have not told bcp which columns to skip. This is done by entering a 0 in the format le for that column. The bcp operation was not run in character mode. You must use character mode with ascii data. To ensure that you are running in character mode, do one of the following: - Launch bcp with the -c option - If using a format le, enter all host types as SYBCHAR. The datatype listed in the format le refers to the datatype of the data le, not the datatype of the column in the target table. Action To locate the source of the problem, issue the bcp command using the -e <error_le> option. bcp then reports the row and column number where it detected the error and writes the row(s) to the error le. Look for one of the problems described in the previous section. Error column information may be misleading
bcp reports the column where it detected the error, not necessarily the
column in which the error occurred. The follow example illustrates this point. A target table is dened as:
fname char(15) lname char(15) birthdate datetime
The bcp format le contains this denition:
Page -11
10.0 3 1SYBCHAR015"-"1col1 2SYBCHAR015"-"2col2 3SYBCHAR08"\n"3col3
The hostle to be copied into the table includes the following rows:
Susan-Smith-12/12/67 Cara-Jones-Parker-05/06/71
The rst record is copied correctly: Susan is copied into Column 1, then the hyphen tells bcp to go to Column 2. In column 2, bcp enters Smith, then sees the hyphen and moves on to Column 3. In Column 3, it enters 12/12/67, sees the newline, and ends the row.
bcp begins the second record by copying Cara into Column 1, reading the hyphen and moving to Column 2. It enters Jones in Column 2, but then interprets the hyphen of Jones-Parker as a column terminator and moves on to Column 3. It now wants to enter Parker, but Column 3 is dened as datetime, bcp then raises a conversion error.
When the operation is run with the -e option, the error is reported in the third column. However, the problem is really in the previous column. To nd this kind of error, you may need to look at all columns in the host le and match them with the format le and the datatype of the corresponding column in the destination table. Versions in Which This Error Is Raised bcp 10.0.x and later bcp using DB-Library calls 10.0.x and later.
Page -12
Unknown version of bcp format-le

Error Number None Message Text
Attempt to read an unknown version of bcp formatfile.
Possible Cause The rst row in the format le used for bcp operations contains the les version number. The only two valid values for the version number in a format le are 4.0 and 10.0, written exactly this way. Any other value will return the unknown version error. You must enter the correct format le version for the bcp version you are running. The following table lists bcp versions and their valid format le versions:
For bcp version:
4.x 10.x, 11.x
Use format le version:

4.0 10.0
Note The format le version is based on the TDS version (Sybases proprietary protocol) and does not correspond exactly to software version.
Action If you are running bcp version 10.0.x or higher, change the format le version to 10.0. If you are running bcp 4.x, change the format le version to 4.0. Versions in Which This Error Is Raised bcp - all versions. Bulk Library 10.0.x and later. bcp calls using DB-Library 4.x and later.
Page -13
Unexpected EOF encountered

Unexpected EOF encountered in bcp data-file.
Possible Cause
bcp detected an end-of-le marker while reading the host data le.
Action Take the following actions to nd the source of the problem: Check the data le for any blank rows and delete them. Sometimes an extra blank row may be found after the last row and should be deleted. Check the data to see if any of the row or column delimiters are embedded in the data values. This confuses bcp and causes unexpected behavior. See Conversion stopped due to syntax error for an explanation of the delimiter issue. If your data le is large, split it into batches to make checking easier. Start with a large batch size, such as 10,000 for a table of 100,000 rows. Determine which batch contains the error. Then narrow your search by setting a smaller batch size and using the -F and -L options to specify the rst and last rows to copy, until you arrive at the problem row.
Note Using the -e error ag to generate an error log will not help you troubleshoot this problem because it is not a bcp error, but a problem in the data.
Versions in Which This Error Is Raised bcp 10.0.x and later. Bulk Library 10.0.x and later. bcp calls using DB-Library 10.0.x and later.
Page -14
Oversized row/overow
Error Number None Message Text bcp 10.0.4
Attempt to bulk-copy an oversized row to the SQL Server.
bcp 11.x
The result is truncated because the conversion/operation resulted in overflow.
Bulk Library 10.x and later

Failed in conversion routine - condition overflow. Note This error is silent in versions of bcp previous to 10.0.4
Possible Cause The character data that bcp is copying into a destination column is larger than the dened width of the column, so the data is truncated. bcp continues the copy operation, but issues a warning. The following example illustrates the truncation error. The publishers table in the pubs2 database is dened as:
pub_id char(5), pub_name varchar(40), city char(20) state char (2)
Trying to insert the following record into this table would trigger a truncation error:
1234, Wagden Books, Washington, D.C.
The width of the state column is 2 but the value as written here is four characters wide. Only the rst two characters, D., are copied into the column state.
Page -15
Action Take one of the following actions as appropriate: Ignore the message, if truncation is not a cause for concern.
x WARNING! Data integrity could be compromised.
Increase the width of the column to accommodate the new values. You need to create a new table to do this. Copy existing data from the old table to the newly dened one, then drop the old table and rename the new one. Modify the data in the host le to the width of the column. If you think you should not be getting this error, check the data to see if any row or column delimiters are embedded in the data values. This alters the position of subsequent elds and can cause data to be copied into the wrong column. Versions in Which This Error Is Raised bcp 10.0.4 and 11.x Bulk Library 10.0.x and later DB-Library 10.0.4
Page -16
Unrecognized datatype found in format le

Error Number None Message Text bcp 10.x
Unrecognized datatype found in format file. ()
bcp 11.x
Unrecognized datatype xxx found in format file. ()
Possible Cause This error may be caused by the following: An invalid datatype describing one or more columns in the host data le was found in the format le. The format le contains a typographical error. Action If the host data le is in ascii format, change all the host datatypes in the format le to SYBCHAR. The datatype in the format le refers to the datatype of data in the host le, not the datatype of the corresponding table column. If you use bcp in native format, refer to the Utility Programs manual for a list of valid types. Alternatively, you can perform the bcp out operation without specifying the -n or -c (native or character) options. bcp will prompt you for the information it needs to automatically create a format le. Versions in Which This Error Is Raised bcp 11.x and 10.0.x. Bulk Library 10.0.x and later. bcp using DB-Library calls 10.0.x and later.
Page -17
blk_init failed, or, Error occurred when attempting to localize

blk_init failed.
Or:
Internal error: An error occurred when attempting to localize the application.
Possible Cause This error may occur when either of the locales les blklib.loc or ctbcp.loc is missing. If the le ctbcp.loc is missing, bcp raises the following error:
Internal error: An error occurred when attempting to localize the application.
If the le blklib.loc is missing, then bcp raises the following error:

blk_init failed.
Action Take one of the following actions to correct the problem: Look for the les blklib.loc and ctbcp.loc in one of the following directories: - $SYBASE/locales/message/<language> (Open Client 11.x) - $SYBASE/locales/<language>/<charset> (Open Client 10.0.x). If one of these les is missing, download the Open Client software from your Sybase CD to a temporary location, then copy the missing le to the appropriate directory. If a le is missing from your CD, call Technical Support. If you are using bcp or Bulk Library 11.x, verify that you are running the task in an Open Client 11.x environment. Check the $SYBASE environment variable to see that it points to the 11.x directory. Open Client 11.x requires locales and conguration les that did not exist in earlier versions of Open Client.
Page -18
Versions in Which This Error Is Raised

bcp 11.x.
Page -19
Bulk alloc failed

Bulk alloc failed. Note This error is returned by an application when it is unable to allocate memory for a bulk copy call and returns CS_FAIL. At this point, Bulk Library error messages have not yet been loaded
Possible Cause Failure to allocate memory following a blk_alloc call may be due to one of the following: A missing locales le, blklib.loc Inadequate memory on the host machine to allocate a bulk descriptor for the bulk copy operation. An invalid connection pointer Action Take one of the following actions to resolve the problem: Look for the le blklib.loc in one of the following directories: - $SYBASE/locales/message/<language> (Open Client 11.x) - $SYBASE/locales/<language>/<charset> (Open Client 10.0.x). If the le is missing, download the Open Client software from your Sybase CD to a temporary location, then copy the missing le to the appropriate directory. If the le is missing from your CD, call Technical Support. If you are using bcp or Bulk Library 11.x, verify that you are running the task in an Open Client 11.x environment. Check the $SYBASE environment variable to see that it points to the 11.x directory. Open Client 11.x requires locales and conguration les that did not exist in earlier versions of Open Client.
Page -20
Check the amount of memory currently available on your machine. Increase physical or virtual memory, or exit other applications to free up resources. Only a small amount of memory is allocated at this time, just enough for internal structures for the bulk descriptor. (Space for tables to be copied is not allocated until the blk_init call.) To check memory resources, use one of the following methods: UNIX Several UNIX commands can give you total and available memory information. Examples of UNIX commands that you can use include: dmesg top (Sun only) hpglance (HP only) See your operating system documentation for commands specic to your platform. Windows NT Check memory statistics as follows: 1. Start up the task manager. 2. Click on the performance tab. The box in the lower left corner of the performance display contains kernel memory information, including total, paged, and non-paged memory. Verify that you allocate a valid connection pointer in the connection allocation statement. See the Common Libraries Reference Manual for more information on
blk_alloc.
Versions in Which This Error Is Raised Bulk Library 10.0.x and 11.x.
Page -21
Identity columns and -E option

The format-file instructed bcp not to copy the identity column, conflicts with the -E option.
Possible Cause This error occurs when both these conditions are present: The format le indicates that the column in the data le corresponding to the identity column in the table should be skipped. bcp is started with the -E ag, which instructs bcp to read the values for the identity column from the data le. This problem is illustrated by the following example. A table is created as follows:
create table test( col1 numeric identity, col2 int, col3 int, col4 int)
A row in the host datale contains:

100,2,3,4
The format le reads as follows:

10.0 4 1 SYBCHAR 2 SYBCHAR 3 SYBCHAR 4 SYBCHAR
0 0 0 0
20 10 10 10
"," "," "," "\n"
0 2 3 4
col1 col2 col3 col4
Although the value of the identity column in the host data le is 100, the 0 in the format le for that column indicates that the column should be skipped. However, the following command explicitly tells bcp to read the values for the identity column:
bcp test in datafile -f bcp.fmt -Uuser -Ppasswd -E
This creates a contradiction that bcp is unable to resolve.
Page -22
Action Take either of the following actions to resolve the problem: Change the format le so you do not skip the values for the identity column. Omit the -E ag and skip the identity column. See the Utility Programs manual for your platform for more details on using bcp with the -E and -N options. (The -N option is used when the data le does not contain identity column values.) Versions in Which This Error Is Raised
bcp Utility 11.x.
Page -23
Missing external conguration data

Error Number None Message Text CS-Library
comn_get_cfg: user api layer: internal common library error: Configuration section bcp not found.
CT-Library
ct_connect(): user api layer: external error: The connection failed because of invalid or missing external configuration data.
Possible Cause Open Client/C 11.x lets you use runtime conguration les for Client-Library applications, including bcp. There is no default runtime conguration le included with your softwareyou must create your own if you wish to use one. You can create, place, and name conguration les as needed. However, when an Open Client application is launched, by default Open Client looks for a conguration le named ocs.cfg under the cong subdirectory of the Open Client 11.x directory. If the le exists, Open Client expects to nd the conguration information for the application in it. The missing conguration error occurs when both these conditions are true: An ocs.cfg le exists The [bcp] section is missing This usually occurs when you have created an ocs.cfg runtime conguration le for use with other applications, but have not created a section for bcp. Action To resolve this problem, take one of the following actions: Create a section for bcp in the ocs.cfg le. Add this section head to the le:
[bcp]
Page -24
You can use the section to set properties for all bcp users or leave it empty.
Note The same error can occur in isql 11.x. if it does not nd a section named [ctisql] in the ocs.cfg le.
You do not need a runtime conguration le to run bcp. If you create a runtime conguration le to use with another application and give it a name other than ocs.cfg, or place it in a directory other than cong, you will not get this error for bcp. See the Open Client-Client Library Reference Manual for information about the ocs.cfg conguration le. Versions in Which This Error Is Raised bcp 11.x.
Page -25
Page -26
Embedded SQL/C and COBOL Error Messages

This chapter includes some of the more common error messages returned by Embedded SQL/C and Embedded SQL/COBOL.
2.
Error numbers may vary or may not be meaningful. Therefore, error numbers are not always listed in this chapter.
Page -1
Unable to nd WHENEVER... statement

Unable to find the SQL statement WHENEVER NOT FOUND. Unable to find the SQL statement WHENEVER WARNING. Unable to find the SQL statement WHENEVER SQLERROR.
Possible Cause To help assure that you have included error handling instructions in your program, the ESQL precompiler looks for three whenever statements: whenever sqlwarning whenever sqlerror whenever not found If the precompiler fails to nd these statements, it issues a warning. Action If you have written your own code to check for errors and warnings, you can do one of the following: Suppress the precompiler warnings by writing a whenever...continue clause for each condition. This instructs the precompiler to ignore errors and warnings. Precompile using the -w ag. This suppresses the warning messages. Simply ignore the precompiler warnings. If you have not written your own error-handling code, add the missing statement to the application. The statements can be placed after the connect statement or ahead of the SQL statements that you want them to affect. The general syntax of the whenever statement is:
Page -2
C language
exec sql whenever {sqlwarning | sqlerror | not found} {continue | stop | goto label | call function_name ([param [, param]...])};
COBOL
exec sql whenever {sqlwarning | sqlerror | not found ] {continue | goto label | stop | program call [using param . . .]) | perform paragraph_1 [through paragraph_2] } end-exec
See the chapter on Handling Errors in the Embedded SQL/C Programmers Manual for more information. See also the online samples located under the $SYBASE/sample/esqlc directory. Versions in Which This Error Is Raised ESQL/C 10.0.x and later. ESQL/COBOL 10.0.x and later.
Page -3
INCLUDE SQLDA not valid in ESQL/COBOL

The INCLUDE SQLDA statement is not valid in ESQL/COBOL.
Possible Cause The SQLDA feature for Dynamic SQL is available only in Embedded SQL/C 11.x. Currently, you cannot use it support SQLDA in ESQL/COBOL. Action Instead of a SQLDA structure, use system descriptors for your Dynamic SQL commands. See the chapter on Dynamic SQL in the Embedded SQL/COBOL Programmers Manual. Versions in Which This Error Is Raised ESQL/COBOL 11.x.
Page -4
Incorrect type of indicator variable

Incorrect type of indicator variable %!.
Possible Causes An indicator variable in ESQL must be a 2-byte integer. For ESQL/C, indicator variables must be declared as type short or CS_SMALLINT. For ESQL/COBOL, indicator variables must be declared as one of the following: PIC S9(2) COMP. PIC S9(4) DISPLAY SIGN LEADING [SEPARATE] PIC S9(4) DISPLAY SIGN TRAILING [SEPARATE] PIC S9(4) COMP-4 PIC S9(4) COMP-5 PIC S9(4) BINARY PIC S9(4) COMP. Action Follow the instructions for your programming environment: C language Change the host type of indicator variables in the program to type short or CS_SMALLINT. COBOL Change the host type of indicator variables in the program to one of the types listed above. Versions in Which This Error Is Raised ESQL/C 10.0.x and later. ESQL/COBOL 10.0.x and later.
Page -5
Unrecoverable error occurred

Error Number 25001 SQL State
ZZ000
Message Text 10.x
Unrecoverable error occurred. Fatal: Immediately report this error to Sybase Technical Support.
11.x
The context allocation routine failed. The following problem caused the failure: Initializing the error cache failed. Unrecoverable error occurred.
Possible Cause Possible causes of this are detailed below: The error usually occurs when there is an incompatibility between the runtime environment and build environment for the application. This is true whether your applications were built using static or dynamic libraries. The error can occur if the cslib.loc le is missing. It is possible, though less likely, that other missing locales les can cause the error. Action Take one of the following actions to resolve this problem: Verify that the application is running on the same version of ESQL version that it was compiled and linked on. Check the SYBASE environment variable in both the development and runtime environments to see that it points to an installation of the same version of ESQL. Also, check your makele for the location of the SYBASE directory used to build the application.
Page -6
See Appendix A, Commands to Find Sybase Versions for instructions on determining ESQL version. Verify that cslib.loc exists in one of the following directories: 10.x - $SYBASE/locales/<language>/<charset> 11.x - $SYBASE/locales/message/<language> Test the online sample program. This sample program is located in one of the following directories: - $SYBASE/sample/esqlc/example1.cp (ESQL/C) - $SYBASE/sample/esqlcob/example1.pco (ESQL/COBOL) Make and test the program under the same conditions as your application. If the sample works correctly, the problem is not your runtime environment. Contact Technical Support. See Appendix B, Open Client/Server 10.0.x and 11.x Runtime Environment for a complete list of locales les required for different versions of ESQL. Versions in Which This Error Is Raised ESQL/C 10.0.x and later. ESQL/COBOL 10.0.x and later.
Page -7
Unexpected CS_PARAM_RESULT
Error Number
-25005 (C)
SQL State
ZF000 (COBOL)
Message Text
Unexpected CS_PARAM_RESULT received.
Possible Cause The ESQL application received output parameters that it was not equipped to handle. Action To correct this problem, rst check the stored procedure denition to see if it has dened output parameters. Log into the server with isql and issue the following command:
sp_helptext stored_proc_name
If the stored procedure denition contains output parameters, edit your ESQL program to recognize them. The following example illustrates how you can code an application when a stored procedure returns parameters. Example An ESQL application needs to execute the following stored procedure:
create proc test_proc (@type char(10), @sales int output) as select @sales=sum(tot_sales) from pubs2..titles where type = @type return
To execute this procedure from ESQL, you might code your application as follows:
Page -8
C language
.... CS_CHAR type[15]; CS_INT retcode, sales; .... exec sql exec :retcode = test_proc :type, :sales output; ....
COBOL
01 01 01 .... exec sql exec :retcode = test_proc :type, :sales output end-exec .... type pic x(15). retcode pic 9999. sales pic S9(9) COMP.
This tells the application to expect return parameters from the sales variable dened in the stored procedure. Versions in Which This Error Is Raised ESQL/C 10.0.x and later. ESQL/COBOL 10.0.x and later.
Page -9
Unexpected CS_ROW_RESULT
Error Number -25006 Message Text
Unexpected CS_ROW_RESULT received.
Possible Cause This error indicates that the ESQL application received results from a select statement that it was not equipped to handle. This may be caused by one of the following conditions: No into :<host_variable> clause provided for a select statement. A select generally contains an into :<host_variable> clause, with host variables provided for every column returned. No into :<host_variable> clause provided for an exec <stored_procedure> statement. If the stored procedure being executed returns a row, the program must contain an into :<host_variable> clause, with host variables provided for every column returned. If a select statement or stored procedure returns multiple rows, you must either store the columns in host variable arrays, or declare a cursor for the exec statement and perform cursor processing. If the program did not previously return the error on executing a given stored procedure, the stored procedure may have changed. According to ESQL rules, a stored procedure can return only one set of row results and can therefore contain only one select statement (though it can include other SQL statements). The ESQL program must be able to handle results from the select within the stored procedure. Action Take the following actions to correct this problem: Change the program code to include an into :hostvar list if one has not been specied for a select or fetch statement. For example:
.... CS_CHARbook_id[8], type[15], price[8]; .... select title_id, type, price from pubs2..titles into :book_id, :type, :price;
Page -10
If multiple rows are expected and no cursor has been declared for the select, use arrays. For example:
.... CS_CHARbook_id[18][8]; CS_CHARtype[18][15], price[18][8]; .... select title_id, type, price from pubs2..titles into :book_id, :type, :price;
Arrays can also be used for results from stored procedures. For example, if a stored procedure was dened as:
create proc test_proc(@type char(10)) as select title_id, type, price from pubs2..titles where type = @type return
Write ESQL your code like this:

CS_CHARbook_id[18][8]; CS_CHARtype[18][15], price[18][8]; .... exec sql exec :retcode = test_proc :type into :book_id, :type, :price;
See the Programmers Manual for your product for examples on using cursors to process multiple rows. If the error occurs during a stored procedure call, check the stored procedure denition to see if it contains more than one select statement. Log into the server with isql and issue the following command:
sp_helptext stored_procedure
This displays the stored procedure code. Correct the procedure or program as necessary. Versions in Which This Error Is Raised ESQL/C 10.0.x and later.
Page -11
Incomplete result set processing

Error Number -16843171 Error Message
ct_results(): user api layer: external error: This routine cannot be called until all fetchable results have been completely processed.
Possible Cause This error occurs when a new command or operation is attempted before all rows from a select, fetch, or exec <stored_procedure> statement have been processed. The error is also raised if: A non-cursor select statement returns multiple rows and the host variables are not arrays. A non-cursor select statement returns multiple rows and the host variable array dened for them is not large enough to hold all returned rows. When you use arrays in non-cursor fetch operations, the size of the array must be large enough to hold all rows returned for that query. If you fetch with a cursor, the array size can be smaller, as the data can be fetched in batches. While a cursor result set is still being processed, you issue new select that returns multiple rows. You are using Dynamic SQL Method 2 and the statement returns multiple rows. With Method 2, prepare and execute, you can only issue statements that return no rows or one row. An attempt to disconnect occurs before all results from the current command have been processed Action To resolve this problem, take the following actions as appropriate: If a new operation or command is initiated during processing of a previous select or fetch, check to see if it is allowable. For example, the following commands do not require all results to be fetched before they can be issued: - In-place cursor updates or deletes
Page -12
- A new command issued on another connection while results on the rst connection are still being processed If the command being issued is not allowed, take one of the following actions: - If a select statement or stored procedure returns multiple rows, use a cursor to fetch the rows or use array variables large enough to store all the returned rows. - Log into the server with isql and issue the same query. See whether you get back more than one row (if using Method 2). See the Programmers Manual for your product for more information on the use of arrays to hold rows from stored procedures and for a discussion of Dynamic SQL methods. Versions in Which This Error Is Raised ESQL/C 10.0.x and later. ESQL/COBOL 10.0.x and later.
Page -13
Error initializing Client Library

Error Number -25016 SQL State ZM000 Message Text
Error initializing Client Library. Severity: Severe
Possible Causes(s) ESQL calls are precompiled to Client Library calls and require a Client-Library runtime environment. This environment includes the $SYBASE/locales directory and the ctlib.loc le. If any of these les is missing, you will get an initialization error. In addition, if the ctlib.loc le is missing, you get the following message:
LAYER = (1) ORIGIN = (1) SEVERITY = (4) NUMBER = (118) ct_init(): Unable to find file $SYBASE/<language>/<charset>/ctlib.loc Note The locales directory structure changed between 10.X and 11.x. This example shows the 10.X directory structure.
Action Check the following locales directories for missing les: $SYBASE/locales/<language>/<charset> (10.x) $SYBASE/locales/message/<language> (11.X) If you are missing a le, take one of the following actions: Download your Embedded SQL software from the CD into a temporary directory, then copy the locales directory to your original installation location. Re-install the Embedded SQL product
Page -14
If the le appears to be missing from the CD, call technical support. See Appendix B, Open Client/Server 10.0.x and 11.x Runtime Environment for a complete list of les required to run the Embedded SQL product. Versions in Which This Error Is Raised ESQL/C 10.0.x and later ESQL/COBOL 10.0.x and later
Page -15
Server does not support TEXT or IMAGE

ct_param(): user api layer: external error: The server does not support parameters of type %1.
(Where%1 can be TEXT or IMAGE.) Possible Cause The program is attempting to use host variables of type CS_TEXT or CS_IMAGE incorrectly. This error occurs when An input parameter of type text or image is passed to a stored procedure. The server does not support parameters of type text or image, so a stored procedure cannot be dened as having text or image parameters. A Dynamic SQL statement contains placeholders corresponding to text or image columns. Dynamic SQL in Sybase Embedded SQL is implemented using temporary stored procedures in the server. Since Adaptive Server does not support text or image parameters, dynamic SQL parameters cannot be either of these types. A host variable of text or image datatype is used as an input parameter in a SQL statement and the application was not compiled with the -y option. Action To resolve this problem, take one of the following actions: Copy the entire text or image value into a local buffer and then use Dynamic SQL Method 1 to send the text of the command and contents of the buffer to the server. The following example demonstrates this method:
Page -16
.... char buffer[10000], cmd[10100]; inti = 0; .... /* for demo purposes, put something ** into the buffer. */ for ( i = 0 ; i < 10000; i++ ) buffer[i] = 'a'; sprintf(cmd, "insert big_table \ values('%s')", buffer ); exec sql execute immediate :cmd; ....
Using this method you can insert or update text or image values up to 65K bytes. Buffers that are larger than this are not supported by Dynamic SQL. ESQL 11.x offers text and image support for regular (nondynamic) SQL and stored procedure statements. Write your code using regular SQL and pre-compile with the -y ag, which enables this support. This feature is available only in ESQL releases 11.x and later. If you incorrectly declared a host variable in the ESQL program as CS_TEXT or CS_IMAGE, change the variable to another datatype. Change the type to char if possible. See Appendix E, Sample Code for Handling Large Text and Image Data for sample code to handle these datatypes. Versions in Which This Error Is Raised ESQL/C 11.x and later.
Page -17
Unterminated C string
Data exception -- Unterminated C string.
Possible Cause This error is raised when the data in a string variable is missing a closing quote. This can happen when: The closing quote was omitted. The data in a character-type host variable was greater than 255 bytes. In this case, any data after the rst 255 bytes, including the quote mark, is truncated. This can happen when you try to insert or update text or image data larger than 255 bytes. Action To resolve this problem, take one of the following actions: For data less than 255 bytes, terminate the string with a closing quote. For text or image data larger than 255 bytes, see the Embedded SQL/C Programmers Reference Manual for information about handling text and image data, and Appendix E, Sample Code for Handling Large Text and Image Data for a sample program. Versions in Which This Error Is Raised ESQL/C 10.0.x and later.
Page -18
Invalid column name

Invalid column name.
Possible Cause One of the column names in the select list is incorrect. It may be spelled incorrectly or entered in the wrong case, or it may not exist in the table. The quoted identier option is set on and the server encounters a string in double quotes in a SQL Statement. The quoted identier option is set on by default in ESQL. When the option is on, the server treats data in double quotes as a column name. For example, the following statement causes an error when CA, in double quotes, is interpreted as a column name:
exec sql select pub_id from publishers where state = "CA";
The following statement, with CA in single quotes, would execute correctly:

exec sql select pub_id from publishers where state = 'CA';
Alternatively, you can precompile the application with the -d ag. This tells the server that the application will not be using quoted identiers and may send character data to the server in double quotes ( ). Precompiling with this ag turns the property off for the session. If you need to use quoted identiers in your code, turn the option on before any statement that requires it. See the section on the set command in the Adaptive Server Enterprise Reference Manual for details on this option. Action Log on to isql and issue the sp_help command for the table. Verify that column names are spelled correctly in your programs select list. If the column list is correct, identify the source of the problem by checking your code for:
Page -19
- SQL statements that contain values within double quotes - The following command, which explicitly turns on the quoted identier option:
exec sql set quoted_identifier on;
By default, ESQL opens up a transaction with the quoted identier option set on. You may wish to edit data strings with double quotes, or you can decide to explicitly set the quoted identier option off before a statement containing double quotes. To turn the option off, enter this line:
exec sql set quoted_identifier off;
You can turn the option off at any point before execution of the statement. However, this turns the option off for the rest of the session. If you need to use quoted identiers in your code, as in this example:
select col1 from table
turn the quoted identier option back on before execution of the statement that requires it. Versions in Which This Error Is Raised This error is returned by Adaptive Server and SQL server and is generic to all supported releases of the server and ESQL.
Page -20
Unchained transaction mode only

Stored procedure <stored_proc_name> may be run only in unchained transaction mode. The `SET CHAINED OFF command will cause the current session to use unchained transaction mode.
Possible Cause For ANSI compliance, ESQL opens the server connection in chained mode by default. However, Sybase stored procedures run in unchained mode by default. This error results when an ESQL transaction running in chained mode calls a stored procedure that requires unchained mode.
Note The mode determines the way transactions are begun and committed. For information about modes, see the Transact_SQL Users Guide.
Action To correct this error, take one of the following actions: Set chained mode off. Add the following command to your program anywhere after the connection is opened, but before the stored procedure is called:
exec sql set chained off; Note If other transactions in your program depend on ESQL running in chained mode, reset the mode as necessary.
Use the -m option when you precompile your program to run in unchained mode. Change the mode of the stored procedure so that it can run in either mode. Log into the server with isql and enter the following command:
Page -21
sp_procxmode stored_procedure, anymode
Versions in Which This Error Is Raised This is an Adaptive Server and SQL Server error and is generic to all supported server and Embedded SQL versions.
Page -22
Invalid precision or scale

ct_param(): user api layer: external error: An invalid precision or scale in the CS_NUMERIC or CS_DECIMAL value was supplied.
Possible Cause This error can occur when: An invalid value is assigned to the precision or scale element of a CS_NUMERIC or CS_DECIMAL type. Precision or scale is not set in a parameter of type CS_NUMERIC or CS_DECIMAL. Action Both output and input parameters, if they are set, require that the precision and scale be valid. Precision, the total number of places for the digits of a number, must be greater than scale, the number of places after the decimal point. Valid values for precision are from 1 to 77 and for scale from 0 to 77. The following sections discuss some issues specic to output and input parameters. Handling output parameters Before you use output parameters of type CS_NUMERIC or CS_DECIMAL, you must dene their precision and scale. Since output parameters do not have a value associated with them until the procedure has been executed, ESQL (and Client-Library) cannot determine the precision and scale to use. Defaults dened for the parameter within the stored procedure cannot be used because the client program does not know how the parameter has been dened in the stored procedure. If you have not dened the precision and scale in the program, do one of the following: - Initialize the elements of the CS_NUMERIC or CS_DECIMAL datatype variable. For example:
Page -23
EXEC SQL BEGIN DECLARE SECTION CS_NUMERIC numeric_var = {18,0,0}; CS_DECIMAL decimal_var = {20,2,0}; CS_INT ret; EXEC SQL END DECLARE SECTION .... /* Execute the stored procedure */ exec sql exec :ret=proc_name :numeric_var :out;
- Explicitly set the precision and scale elements of the structure. For example:
.... CS_NUMERIC numeric_var; .... /* Do this before referencing the output ** parameter in the stored procedure call. */ numeric_var.precision = 18; numeric_var.scale = 0; .... /* Execute the stored procedure */ exec sql exec :ret=proc_name :numeric_var :out; ....
Any valid precision or scale value can be used in the denition. However, you should dene the precision and scale so that they are large enough to hold the return value.
Note C only: It is not necessary to map a numeric or decimal server data type to a CS_NUMERIC or CS_DECIMAL type. You can use any compatible C type, such as oat, double, or int (if the value of scale is 0).
For the denition of CS_NUMERIC and CS_DECIMAL structures, see the le cstypes.h located in the $SYBASE/include directory. Handling input parameters If the error is raised on an input parameter, verify that the parameter is assigned a value before it is called. If you create a host variable to hold numeric or decimal query results, then use the variable as an
Page -24
input parameter for another SQL statement, you could get an error if the rst query did not yield any results. If no value was retrieved into the host variable, the precision and scale would not be set for the input parameter. The following example illustrates this problem:
.... CS_NUMERIC num_var; .... exec sql select num_col from test_table into :num_var where int_col > 10000; .... exec sql exec :ret_status = test_proc :num_var;
This select statement retrieves a value into a numeric host variable, and the following statement passes this value as an input parameter to a stored procedure. If the select statement returns a value, ESQL will correctly set the precision and scale for the host variable. However, if no value is retrieved, the input parameter does not have a value, precision, or scale and an error is raised. To work around this issue, you can do any of the following Take the actions listed for output parameters Set the indicator variable (see the last action) Check the number of rows returned by the last SQL command Instructions for checking rows and setting the indicator variable are given in the sections below. Checking the number of rows returned Use one of these methods to check the number of rows returned: To check the number of rows returned in ESQL/C 10.x, do the following:
.... exec sql select num_col from test_table into :num_var where int_col > 10000; .... /* Use the sqlca.sqlerrd[2] structure variable to * see if the last query returned any rows. */ if ( sqlca.sqlerrd[2] > 0 ) /* Rows were returned */ /* Execute the procedure - we have a valid
Page -25
* input value */ exec sql exec :ret_status = test_proc :num_var; /* Execute the procedure - with a null * input value */ indic = -1; exec sql exec :ret_status = test_proc :num_var :indic;
To check the number of rows in ESQL/COBOL, do the following:

.... exec sql select num_col from test_table into :num_var where int_col > 10000 end-exec .... * Use the SQL--ROWSREAD variable to see * if the last query returned rows. if ( SQL--ROWSREAD > 0 ) * Execute the procedure - we have a valid * input value exec sql exec :ret_status = test_proc :num_var endexec * Rows were returned * Execute the procedure - with a null input value move -1 to INDIC. exec sql exec :ret_status = test_proc :num_var :indic end-exec
Setting the indicator variable You can also set the indicator variable for the select or in any case where the input parameter may be NULL. Initialize the indicator variable before executing the statement. The following example shows how to do this for a select statement:
Page -26
.... indic = -99; /* Initialize this variable */ exec sql select num_col from test_table into :num_var :indic where int_col > 10000 ; if ( indic == -1 ) /* handle the input param accordingly ** before executing the stored procedure. */ ....
The following example shows how to use an indicator variable when the program calls a stored procedure:
CS_SMALLINT indic; .... CS_NUMERIC numeric_input; CS_SMALLINT indic; .... indic = -1; exec sql exec :ret=proc_name :numeric_input :indic; ....
Versions in Which This Error Is Raised This error is raised by: ESQL/C 10.0.x and 11.x. ESQL/COBOL 10.0.x and 11.x.
Page -27
Page -28
Client Library Error Messages

This chapter includes some of the more common error messages returned by Client-Library.
3.
Client-Library error numbers by themselves are not unique. Each error has unique a combination of elements, including severity, layer, and origin. Therefore, error numbers are not listed separately in this section. For an explanation of the derivation of the error indentiers, see Appendix C, How to Interpret Client-Library Error SQLCODEs.
Page -1
Call to connect two endpoints failed

Message Text
Number: (4) Severity (5) Layer (5), Origin (3) text: ct_connect(): network packet layer: internal net library error: Net-Lib protocol driver call to connect two endpoints failed.
Possible Cause This error is raised by the network layer when the client application is unable to connect to the server. The most common reasons for this are: The target server is not running. There is a problem resolving the network address for the server, which may be due to: - an error in interfaces or sql.ini le - the setting of the DSQUERY environment variable - an incorrect server name entered at the command line or in the application The server machine is down or not accepting connections. Action Because a variety of issues can cause a failure to connect, as well as related errors, this section takes you through a systematic check of the conditions necessary to connect. You may not need to perform all steps. The troubleshooting approach breaks down into three main parts: 1. Is the server running and listing on the expected port? 2. Can the client application locate the server on the network? 3. Can the client connect to the remote server? 1. Is the server running and listing on the expected port? Check that the server is running and listening on the expected port. The server can be an Open Server as well as an Adaptive or SQL Server. The following sections tell you how to do this on UNIX, Windows, and VMS.
Page -2
Checking the server on UNIX On UNIX platforms, try issuing this command from the machine the server is installed on:
netstat -a | grep <port_no>
where port_no is the number of the port the server is listening on. You can get the name of the server machine and the port number from the interfaces le. If the output shows a value of LISTEN, the server is up and running on that port. For example, if the server that we wish to connect to is running on a machine called SARAH on port 34987, on log into SARAH and enter:
netstat -an | grep 34987
If the server is running on SARAH, the output looks like this:

sarah.34987 *.* 0 0 0 0 LISTEN
Checking the server on Windows NT: On NT platforms using TCP/IP, enter:

netstat -an
Check the output to see if a server is listening on the port. Checking the server on OpenVMS on VAX or AXP: For VMS, the command you use to test whether the server is running depends on the network protocol, as shown here: - For AXP and VAX OpenVMS using TCP/IP, you can see a server process by running the command:
show system
If the server we wish to connect to is called SYBASE and is running, the above command would generate an output similar to:
3EC00847 SYBASE_SQL HIB 6 1380 0 02:04:27.96 1141 1424
- If you are using decnet, you can tell if a server is up by issuing the command:
mc ncp show known objects
Page -3
Look for a name with the value OBJ_###, where ### is the port number in the interfaces le. For example, the server SYBASE had the following entry in the interfaces le:
SYBASE master decnet ether MUDHEN 200
To see if this server is running on port 200 on MUDHEN, issue the command:
$ mc ncp show known objects
Look for output similar to:

OBJ_200 200 3EC00847 Note On both VAX and AXP platforms, VMS upshifts (translates logical values to uppercase). For example, if your interfaces le contains an entry for the server sybase (lowercase) and you dene the DSQUERY logical as follows: define DSQUERY sybase you get a connection error because VMS upshifts the value and looks for an interface entry for SYBASE in uppercase. To be able to use the same case, issue the dene command using double quotes around the name: define DSQUERY sybase This problem does not occur on UNIX platforms.
If you are still not sure whether the server is running, check with your database administrator. 2. Can the client application locate the server on the network? If you are sure the server is running, make sure your application can locate the server on the network. Perform these checks: Check the SYBASE variable to make sure that it points to the correct location of your Open Client installation. This lets the client locate the interfaces (UNIX, VMS) or sql.ini (NT) le. Verify that an entry exists in the interfaces or sql.ini le for the server the application wants to connect to. Check the DSQUERY environment variable to make sure that it points to the server the client wants to connect to.
Page -4
If the error occurred when you tried to connect using isql or bcp, and you used the -S <server_name> parameter, verify that you entered the correct server name. When using isql or bcp, you must either set the DSQUERY environment variable or specify a server name with -S. If the error is raised by a Client-Library application, check the second parameter of the ct_connect call, which species the server name. If it is set to NULL, then Client-Library uses the value of DSQUERY. If the parameter is not NULL, then the name specied in this call is used to connect to the server. If the server name is passed at runtime to the application, verify that the name being passed exists in the clients interfaces le.
If the client application uses the CS_IFILE property to specify a location other than $SYBASE for the interfaces le, verify that the le exists at that location. If the server name is passed at runtime to the application, make sure that the length parameter of the ct_connect call, which species the length of the server name, is either CS_NULLTERM or is a strlen of the host variable.
Note If you request a connection to a server name that does not exist, you get the not found error rather than the endpoint error: ct_connect(): directory service layer: internal directory control layer error: Requested server name not found. Follow the steps above to locate the source of the error.
3. Can the client connect to the remote server? If the server is running and you are trying to connect from another machine, verify that you can connect to the server machine from the client machine: Issue the telnet command using the name of the machine on which the server is running to verify that you can connect to that machine.
Page -5
Use sybinit or dsedit on the client machine to add an entry to the interfaces or sql.ini le for the server, if necessary. These tools will ensure that the server entry is written in the correct format. Versions in Which This Error Is Raised Client-Library 10.0.x and later. isql, bcp, defncopy 11.x.
Page -6
Attempt to connect to the server failed

Message Text
Number: (44) Severity (4) Layer (4), Origin (1) text: ct_connect(): protocol specific layer: external error: The attempt to connect to the server failed.
Possible Cause This error is raised by isql, bcp, and defncopy, as well as Client-Library applications. The error is usually preceded by an error from the server that explains why the client connection attempt failed. Common server errors that can cause a failure to connect include the following: An incorrect user name or password that causes the login attempt to fail. When this happens, the server generates an error message like the following:
Msg 4002, Level 14, State 1: Line 1: Login failed.
Then Client-Library raises the connection error. An invalid packet size specied in the CS_PACKETSIZE property by a Client-Library application, or with the -A option for isql and bcp. For example, suppose the default packet size for a server is 512, the max default packet size is 1024, and you make the following login request:
isql -Usa -P -A2048
The login attempt triggers the following error from the server:
The packet size (2048) specified at login time is illegal. Legal values are between 512 and 1024.
This message is then followed by the Client-Library connection error message. Action To resolve this problem, do the following: Verify that your user name and password are valid. If the error is raised by a Client-Library application, verify that the values passed to CS_USERNAME and CS_PASSWORD are correct. If
Page -7
your are using isql, bcp, or defncopy, check the values of the U and P options. If the error is accompanied by a server error referring to an invalid packet size, log into the server with isql and check the default and maximum packet size run values. Use the following command:
1> sp_configure "default network packet size" 2> exec sp_configure "max network packet size" 3> go
The value specied for CS_PACKETSIZE in the application, or with the -A option for isql and bcp, must be a multiple of 512 that lies within the range from the default and to the maximum packet size. See the System Administration Guide for more information on setting packet size. Versions in Which This Error Is Raised Client-Library 10.0.x and later isql, bcp, defncopy 11.x.
Page -8
Maximum number of connections already opened

Message Text
Number: (6) Severity (1) Layer (1), Origin (1) text: ct_connect(): user api layer: external error: The maximum number of connections have already been opened.
Possible Cause This error occurs when an application tries to open more connections to the server than the limit set for the CS_MAX_CONNECT property in the ct_cong call. The default value is 25. The value applies to the number of connections per context. Action To resolve this problem, take the following actions, as appropriate: Check the application source code for the value of the CS_MAX_CONNECT property. Then check the code for the number of connection requests. If the value of the CS_MAX_CONNECT property is smaller than the number of connection requests, or if CS_MAX_CONNECT is missing, set the value to a number large enough to accommodate the connection requests. Change the code to reuse or close some connections.
Note A different error is raised when the number of connections attempted is more than the number of users the server is congured for. See Net-lib operation terminated due to disconnect for a description of this error.
Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -9
Net-lib operation terminated due to disconnect

Message Text
Number: (6) Severity (5) Layer (5), Origin (3) ct_results(): network packet layer: internal net library error: Net-Library operation terminated due to disconnect. Note This error message occurs only with UNIX versions of Client-Library.
Possible Cause This error is raised by the network services layer when a client disconnects abnormally. This can happen when: The server refuses a connection because it would exceed the maximum number of user connections that the server is congured for. A problem in the network causes connections to be dropped. The client has been killed. Action To resolve this problem, take the following actions, as appropriate: To see if you have exceeded the congured server value for the maximum number of user connections, log into the server with isql and issue this command:
1> sp_configure user connections 2> go
The run value is the value of the maximum number of users parameter. Some of the connections are used for housekeeping tasks, so the number of connections your application may open is less than the maximum number of users allowed. See the System Administration Guide for an explanation of the number of user connections parameter. Then, issue sp_who to see how many connections have already been established. The sp_who output may show a lower number of connections than existed when the error occurred. You may need to monitor the output continuously while the application runs to get an accurate picture.
Page -10
If you need more connections than the server allows, ask your database administrator to raise the value of the number of maximum connections parameter. Check your network for lost packets. You may want to use a sniffer or equivalent tool to do this. On UNIX platforms, check the value of the tcp ip abort interval. If your client application is waiting for the server to return results from a large or time-consuming query, the operating system may disconnect the client. Consider disabling tcp no delay. Check the operating system parameter for the number of le descriptors for both the client and server machines. On most UNIX machines, you can get this value by issuing the limit or ulimit -a command. If you need to open more connections than the number of le descriptors allowed, ask the UNIX system administrator to set this parameter to a higher value. Versions in Which This Error Is Raised Client-Library 10.0.x and later isql, bcp, defncopy 11.x.
Page -11
Routine cannot be called while results are pending

Message Text
Number: (16) Severity (1) Layer (1), Origin (1) text: ct_command(): user api layer: external error: This routine cannot be called while results are pending for a command that has been sent to the server.
Possible Cause In general, all results from one set of commands sent to the server must be completely processed before a new command can be initiated on the same command structure. This error can occur when an application attempts to: Send a new command on the same command structure (make a call to ct_command) before all results from the previous command have been processed. Drop a command structure whose results have not been completely processed. Close a cursor before results have been fetched. Action To resolve the problem, take the following actions; Check your code to verify that you call ct_results after a ct_send call, then check your result processing loop to see that it processes all results until ct_results returns a value of CS_SUCCEED. The result type retuned for every logical command should be CS_CMD_DONE. For more information on result processing and logical commands, see the section on ct_results in the Client-Library/C Reference Manual, which includes sample code that shows a typical result processing loop. Verify that both ct_command calls on the previous command structure and ct_cmd_drop calls are initiated only after all the results for the previous command have been processed and ct_results returns a value of CS_SUCCEED.
Page -12
Page -13
Command structure has results pending

Message Text
Number: (49) Severity (1) Layer (1), Origin (1) text: ct_command(): user api layer: external error: This routine cannot be called because another command structure has results pending.
Or:
ct_close(): user api layer: external error: This routine cannot be called because another command structure has results pending.
Possible Cause This error can occur when an application: Initiates a new command on a new command structure before all of the results from a previous command have been processed. Attempts to close a connection where results are pending. Action To resolve the problem, take one of following actions, as appropriate: Check your code to verify that you are not issuing a new command on a new command structure until all results from a previous command structure have been completely processed. Check your results processing loop. It must process all results returned until ct_results returns a value of CS_SUCCEED. For more information on result processing, see the section on
ct_results in the Client-Library/C Reference Manual.
If the error is raised on a ct_close statement, and you want the connection closed when a certain condition has been met, whether or not all results have been processed, make the ct_close call using the CS_FORCE_CLOSE option. This closes the connection regardless of pending results. When you do this, however, the client does not notify the server of the disconnect. Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -14
Illegal value CS_DATAFMT structure

Message Text
Number: (46) Severity (1) Layer (1), Origin (1) text: ct_bind(): user api layer: external error: An illegal value of %1! was placed in the %2! field of the CS_DATAFMT structure.
Or:
ct_param(): user api layer: external error: An illegal value of %1! was placed in the %2! field of the CS_DATAFMT structure.
Possible Cause This error can occur for the following reasons: You have not placed a value in a required eld. For example, if you pass parameters using ct_param and do not set the status eld of the CS_DATAFMT structure, you get the following error:
ct_param(): user api layer: external error: An illegal value of 0 was placed in the status field of the CS_DATAFMT structure.
The error occurs because the status eld must be set to CS_INPUTVALUE or CS_RETURN when you dene parameters. An illegal value is placed in a eld of the data format structure on a ct_bind or ct_param call. Fields include name, namelen, maxlength, datatype, count, locale, usertype, precision, scale, status, and format. For example, binding a column result of type char to a host variable, using the following data format structure, causes the error:
... CS_DATAFMT datafmt; ... datafmt.datatype = CS_CHAR_TYPE; datafmt.maxlength = -1; ... ct_bind ( ... ); ... ct_bind(): user api layer: external error: An illegal value of -1 was placed in the maxlength field of the CS_DATAFMT structure.
Page -15
The error occurs in this case because maxlength must be a nonnegative number for variable length datatypes. (The maxlength parameter is ignored for xed-length types.) The call sequence is incorrect. For example, when you use cursors and Dynamic SQL, you must make a describe output call after a cursor has been opened. A call to describe output before the cursor is opened can result in an illegal value in the status eld of the data format structure. Action To resolve the problem, take the following actions: See the sections on the CS_DATAFMT structure in the Open Client Client-Library/C Reference Manual for a list of valid values for each eld in a data format structure. See also the sections on the ct_bind and ct_param calls. Check the sequence of calls for describing input and output parameters. Usually, input and output parameters are dened before the command is sent to the server. Calls to describe results must be made after the command has been sent to the server. Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -16
Parameter must be 0
Message Text
Number: (4) Severity (1) Layer (1), Origin (1) text: When %1! is NULL the %2! parameter must be 0.
The following are examples of actual errors:

ct_connect(): user api layer: external error: When server_name is NULL the snamelen parameter must be 0. ct_remote_pwd(SET): user api layer: external error: When password is NULL the pwdlen parameter must be 0. ct_remote_pwd(SET): user api layer: external error: When server_name is NULL the snamelen parameter must be 0.
Possible Cause The value of the length parameter for the property named in the error message must be 0 when the buffer parameter value is NULL. The error occurs when you set the length parameter to a value other than 0. The most common reason for the error is specifying a length of CS_NULLTERM with a NULL buffer parameter. The error usually occurs on ct_connect or ct_remote_pwd calls. For example, the following call causes the error:
ct_connect ( *conn_ptr, NULL, CS_NULLTERM ); ct_connect(): user api layer: external error: When server_name is NULL the snamelen parameter must be 0.
Action If you specify a value for the buffer parameter, such as a server name or password, then the length parameter must be set to CS_NULLTERM or strlen(buffer). However, if you want the buffer parameter to be NULL (for example, on a ct_connect call where you want to get the server name from the DSQUERY variable), set the length to 0 or to CS_UNUSED. Check the Open Client Client-Library/C Reference Manual page for the specic parameter for valid values.
Page -17
Versions in Which This Error Is Raised: Client-Library 10.0.x and later.
Page -18
Illegal value for parameter

Message Text
Number: (5) Severity (1) Layer (1), Origin (1) illegal value of %1 given for parameter %2. An
Possible Cause This error usually occurs because a statement contains an invalid column or item number. Placeholder%1 in the error text usually contains the invalid column or item number. Placeholder%2 is usually replaced by the words item or column. The error text looks similar to these examples:
An illegal value of %1 given for parameter item. An illegal value of %1 given for parameter column.
The error can occur with ct_bind, blk_bind, ct_get_data, ct_data_info, ct_keydata, and ct_describe calls. The error message always includes the call on which the error was raised. An item is usually a piece of data that is returned from the server and needs to be bound to a host variable. It could, but does not necessarily, correspond to a column in the table; other items such as return statuses or output parameters from stored procedures can also be bound or described. For example, a value of 0 for a ct_bind item causes the following error:
ct_bind(): user api layer: external error: An illegal value of 0 given for parameter item.
The term column, on the other hand, usually corresponds to a particular column, such as one specied in a ct_get_data call. Example of incorrect column reference in a loop The error can occur when you use a loop to perform data description and your loop is coded with a value outside the range of valid column numbers. The following example illustrates this problem. Suppose you send this command to the server:
select pub_id, pub_name from publishers
You need to bind the results from the two columns to variables, so you write the following code:
Page -19
.... CS_RETCODE retcode; CS_INT i, num_cols; CS_DATAFMT datafmt; CS_SMALLINT indic; .... /* get the number of columns */ retcode = ct_res_info(cmd_ptr, CS_NUMDATA, &num_cols, CS_UNUSED, NULL) ; .... for ( i = 0 ; i <= num_cols ; i++ ) { /* describe the data format fields */ .... retcode = ct_bind (cmd_ptr, i, &datafmt, rowbuffer[i], NULL, &indic) ; ....
However, the counter i, which has been set to 0, is also used as the rst column number, generating this error:
ct_bind(): user api layer: external error: An illegal value of 0 given for parameter item.
Another common cause of the error on a ct_bind call is a loop condition that is hard-coded to the number of result items expected. This can cause problems with a statement such as:
select * from table_name
if the table denition changes, changing the number of items returned. Error on a blk_bind call The error message for a blk_bind call is slightly different. For example, suppose that you want to bulk copy a table with three columns, but the blk_bind call incorrectly refers to four columns:
.... retcode = blk_bind(blkdesc, 4, &datafmt, (CS_VOID *)dptr->pub_name, &datalen[1], NULL);| ....
The error message would look like this:

blk_bind(): blk layer: user error: Parameter colnum has an illegal value of 4
Page -20
Action In general, since this error is caused by an invalid column or item number, check the number for validity. Use one of the following methods: Check your select statement list for the number of columns to be returned and match them with the column numbers specied in your call. If the error occurs on a ct_bind or ct_describe loop, call ct_res_info with CS_NUMDATA to get the number of columns returned for the SQL statement executed. Take the value returned, N, and call ct_bind or ct_describe 1 to N times. If your loop is coded with a value outside this range, change your code as illustrated below. For the following example, refer to the code in the section Example of incorrect column reference in a loop. This code used a variable for the number of columns, but the variable was set to the value of the loop counter, which started at 0. The following code correctly starts the loop counting at 1:
.... CS_RETCODE retcode; CS_INT i, num_cols; CS_DATAFMT datafmt; CS_SMALLINT indic; .... /* get the number of columns */ retcode = ct_res_info(cmd_ptr, CS_NUMDATA, &num_cols, CS_UNUSED, NULL) ; .... for ( i = 1 ; i <= num_cols ; i++ ){ /* describe the data format fields */ .... retcode = ct_bind (cmd_ptr, i, &datafmt, rowbuffer[i], NULL, &indic) ; .... }
If you hard-coded a loop to the number of expected columns, change the code to use a variable for the number of columns, as the example above. If the error occurs on a bulk copy in operation, check your host data structure or le to make sure that you have the correct number of columns. Also check the corresponding table to see if it has the same (or a smaller) number of columns.
Page -21
If the error is on a blk_bind call, verify that the number of columns specied is equal to the number of columns you copied. If the error is on a ct_get_data or ct_data_info call, verify that the column numbers specied to these calls match the text or image columns in the select statement. Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -22
Server does not support parameters of type text/image

Message Text
Number: (48) Severity (1) Layer (1), Origin (1) ct_param(): user api layer: external error: The server does not support parameters of type TEXT.
Or:
ct_param(): user api layer: external error: The server does not support parameters of type IMAGE.
Possible Cause The program is attempting to use host variables of type CS_TEXT or CS_IMAGE as input parameters. These datatypes, as well as userdened text or image datatypes, are invalid when used as parameters and or dened in a CS_DATAFMT structure. Text and image datatypes cause the error when used as: An input parameter passed to a stored procedure Placeholders corresponding to text or image columns in a Dynamic SQL statement A host variable used as an input parameter in regular a SQL statement Action To resolve the problem, take one of the following actions: Adaptive Server does not support parameters of type text or image, therefore a stored procedure cannot be dened with text or image parameters. If the problem occurs when the client program calls a stored procedure, check the host variables in the program and change incorrect ones to valid types. See the section on Using CS_DATAFMT structures in the Client-Library/C Reference Manual for a list of valid datatypes for parameters. Use regular text and image handling routines to handle this type of data, rather than using parameters. See the section text and image Data Handling in the Open Client Client-Library/C Reference Manual for details.
Page -23
Dynamic SQL in Sybase creates temporary stored procedures in the server. Because the server does not support text or image parameters, Dynamic SQL cannot use them either. To work around this restriction, try one of the following methods: - Change the type of the parameter to char, if possible (the length of the data must be less than 255 characters). - Copy the entire text or image value into a local buffer, then use Dynamic SQL Method 1 to send the text of the command and the contents of the buffer to the server, as in this example:
.... CS_COMMAND *cmd; char data[10000], buffer[10100]; int i = 0; CS_RETCODE retcode; .... /* for demo purposes, stuff something ** into the buffer. */ for ( i = 0 ; i < 10000; i++ ) data[i] = 'a'; sprintf(buffer, "insert big_table \ values('%s')", data ); retcode = ct_command (cmd, CS_LANG_CMD, buffer, CS_NULLTERM ..); .... Note You can use this method to insert or update text or image values up to 65K bytes. Buffers larger than 65K are not supported by Sybase Dynamic SQL.
Page -24
No driver of the requested protocol class

Message Text
Number: (3) Severity (4) Layer (5), Origin (3) text: ct_connect(): network packet layer: internal net library error: No driver of the requested protocol class is available.
Possible Cause This error is usually raised by the network layer during a ct_connect call when the server entry in the clients interfaces le is in the wrong format for the network protocol. For example, a TLI-based network protocol such as Sun Solaris looks for a server entry in tli format and a socket-based protocol such as HP-UX looks for a corresponding socket-based tcp/ip format. A TLI-based entry looks like this:
SYBASE query tli tcp /dev/tcp \x000213e09d852c880000000000000000 master tli tcp /dev/tcp \x000213e09d852c880000000000000000
A socket-based tcp/ip entry for the same server looks like this:
SYBASE query tcp ether prod1 5088 master tcp ether prod1 5088
If the server entry in the clients interfaces le is in a format different than the one Client-Library expects for your operating system, you will get an error.
Note Client-Library 11.x and later can interpret both tli and socket entries on either network protocol.
Action To correct the error, use a tool such as sybinit or dsedit to reenter the server address. These tools will ensure that the entry is valid for your platform. See the server installation or conguration guide for more information on interfaces le formats.
Page -25
Versions in Which This Error Is Raised Client-Library 10.0.x.
Page -26
Data NULL when dening input parameters for cursors

Message Text
Number: (119) Severity (1) text: ct_param(): user api The data must be NULL when parameters for a ct_cursor command Layer (1), Origin (1) layer: external error: defining CS_INPUTVALUE (CS_CURSOR_DECLARE)
Possible Cause You must dene host variable formats for a cursor command whose SQL string contains host variables before you can pass values to the cursor. The formats should be dened soon after the cursor declare statement. Dening variable formats at declare time prepares the cursor for input at open time. However, the data values for these variables are not passed until you open the cursor. The error occurs when you pass the values to a ct_param call for a cursor before the cursor open call. Action To nd the source of the error, check your source code for the sequence of calls for a cursor and make necessary corrections. The usual sequence is:
... ct_cursor ( ... CS_CURSOR_DECLARE ... ) .. define the dataformat structure for input params ct_param .. define parameters if any, but do not pass the values ct_cursor ( ... CS_CURSOR_OPEN ... ) ct_param .. pass the data values for each parameter defined with the cursor declare ct_send ct_results
The following code sample illustrates the sequence:
Page -27
.... #define RETURN_IF(a,b) if (a != CS_SUCCEED) \ {fprintf(stdout,"error in %s\n",b); return a;} .... CS_RETCODE open_cursor ( cmd_ptr ) CS_COMMAND *cmd_ptr; { CS_RETCODE ret ; int sales = 100; CS_DATAFMT datafmt ; /* Declare the cursor for a SQL select statement ** with input host variabvles ( if any ). */ ret = ct_cursor ( cmd_ptr, CS_CURSOR_DECLARE, "sel_cursor", CS_NULLTERM, "select title_id from pubs2..titles where \ total_sales > @sales", CS_NULLTERM, CS_FOR_UPDATE ); RETURN_IF ( ret, "ct_cursor: declare "); /* define the dataformat structures for each input ** parameters one by one. */ memset(&datafmt, 0, sizeof (datafmt)); strcpy(datafmt.name, "@sales"); datafmt.namelen = CS_NULLTERM; datafmt.datatype = CS_INT_TYPE; datafmt.maxlength = CS_UNUSED; datafmt.status = CS_INPUTVALUE; datafmt.locale = NULL; /* Call ct_param to specify the input paramter defin** ition, but pass the 'data' paramter as NULL. */ ret = ct_param(cmd_ptr, &datafmt, NULL, CS_UNUSED, CS_UNUSED) ; RETURN_IF( ret, "ct_param select"); /* Open the cursor */ ret = ct_cursor ( cmd_ptr, CS_CURSOR_OPEN, NULL, CS_UNUSED, NULL, CS_UNUSED, CS_UNUSED ); RETURN_IF ( ret, "ct_cursor: open "); ; /* Call ct_param with the actual data values for the ** input params. */ ret = ct_param(cmd_ptr, &datafmt, (CS_VOID *)&sales, sizeof(CS_INT), CS_UNUSED) ;
Page -28
RETURN_IF( ret, "ct_param select"); /* Send the cursor command to the server */ ret = ct_send ( cmd_ptr ); RETURN_IF ( ret, "ct_send : cursors "); /* Call the result processing routine */ ret = handle_returns ( cmd_ptr ) ; RETURN_IF ( ret, "ct_results : cursors "); .... }
Page -29
Passing parameters by name and position

Message Text
Number: (47) Severity (1) Layer (1), Origin (1) text: ct_param(): user api layer: external error: When defining parameters, names must be supplied for either all of the parameters or none of the parameters.
Possible Cause When you dene parameters for a RPC command or language command using a ct_param call, you must dene names for all the parameters, or none of them can be called by name. If you do not specify names, the parameters are passed by position. The parameter name is specied in the name eld of the CS_DATAFMT structure. The following example demonstrates how the error occurs. The following code denes two parameters for a command, the rst with no name and the second with the name @price_param:
/* Define the first input parameter */ datafmt.datatype = CS_CHAR_TYPE; ... ct_param ( .... ); /* Define the second input parameter */ strcpy(datafmt2.name,"@price_param"); datafmt2.namelen = CS_NULLTERM ; datafmt2.datatype = CS_FLOAT_TYPE; ... ct_param ( .... );
If you then issue the command using two parameter names, @type and @price, in the select list, you will trigger the error:
select title_id, type, price from pubs2.dbo.titles where type = @type_param and price >= @price_param
Action To resolve the error, modify the dataformat structures for the parameters dened for a command so that either all of them or none of them have parameter names dened. Do this for both input and output parameters.
Page -30
The name you dene for the parameter must be the same name used by the stored procedure or language command for that parameter. The following example illustrates how to name parameters:
... ct_command ( .., CS_LANG_COMMAND , "select select title_id, type, price from pubs2.dbo.titles where type = @type_param and price >= @price_param", .. ); ... /* Define the first input parameter */ strcpy(datafmt.name,"@type_param"); datafmt.namelen = CS_NULLTERM ; datafmt.datatype = CS_CHAR_TYPE ; datafmt.status = CS_INPUTVALUE ; ... retcode = ct_param ( cmd_ptr, &datafmt, (CS_VOID *)type, strlen(type), CS_UNUSED); ... /* Define the second input parameter */ ... strcpy(datafmt2.name,"@price_param"); datafmt2.namelen = CS_NULLTERM ; datafmt2.datatype = CS_FLOAT_TYPE ; datafmt2.datatype = CS_CHAR_TYPE ; ... retcode = ct_param ( cmd_ptr, &datafmt2, &price, sizeof(CS_FLOAT), CS_UNUSED); ...
See the Adaptive Server Enterprise Reference Manual for more details on passing parameters to stored procedures by name and position. Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -31
Bind resulted in truncation

Message Text:
Number: (132) Severity (1) Layer (1), Origin (4) text: ct_fetch(): user api layer: internal common library error: The bind of result set item %1 resulted in truncation.
Possible Cause This error occurs when you bind data to a host variable, specifying the size of the data in the maxlength eld of the CS_DATAFMT structure, then retrieve data using ct_fetch that is larger than the size you specied. If you are retrieving variable length data and maxlength is smaller than the result data, no data is copied into the host variable and ct_fetch returns a CS_ROW_FAIL for this row. If you specied an indicator variable at ct_bind time and truncation occurred, the length of the data is stored in the indicator variable. Action To resolve the problem, set the maxlength eld of the CS_DATAFMT structure large enough to accommodate larger data sizes. Use one of the following methods: Set the bind variable to the maximum value possible for the variable length datatype. For character elds, you can set maxlength to 255, as this is the maximum length for character data.
Call ct_describe to get the maxlength of the data (as well as other result data descriptions) before calling ct_bind. See the ct_describe page in the Open Client Client-Library/C Reference Manual for more information on this call. Set your dataformat.maxlength to the current maximum length of a column. To nd this value, log into the server with isql and issue the following command:
1> select max(datalength(column_name)) 2> from table_name 3> go
Set your dataformat.maxlength to this value, plus 1 (for the null terminator). This value can change as the data in the table column changes.
Page -32
Note The maxlength eld is ignored for xed length datatypes dened in the CS_DATAFMT structure.
Specify an indicator variable for each item bound to a host variable. Specify the indicator variable at ct_bind time so that, when data is fetched into the corresponding host variable, information about the data can be stored in the indicator variable. A value greater than 0 contained in the indicator variable is the length of the data and indicates that data truncation has occurred. You can set maxlength to the value in the indicator variable, plus 1 (for the null terminator). See the Open Client Client-Library/C Reference Manual section on ct_bind for more details. Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -33
Read from the server has timed out

Message Text
Number: (63) Severity (2) Layer (1), Origin (2) text: ct_results(): user api layer: internal Client Library error: Read from the server has timed out.
Possible Cause The time set by the Client-Library application to wait for a server response to either a command or login attempt has elapsed. By default, the timeout value for commands is CS_NO_LIMIT; that is, Client-Library waits indenitely for a response from the server on a command request. However, you can limit the time an application waits for a response by setting the CS_TIMEOUT property in the application or in a runtime conguration le. A timeout during command processing indicates that the applications request is blocked because the server is executing a request from another session or connection that requires an exclusive lock on the page or table. The error can also occur on a login request. The default timeout value for a server login is 60 seconds. The application can increase or decrease this time with the CS_LOGIN_TIMEOUT property. The error occurs when the server does not respond within the specied time to a login request made by the ct_connect call. For example, the timeout error on login can occur when the server machine is down. Because no response is not considered an error, the network does not signal the client that an error has occurred. However, if a login timeout period has been set with CS_LOGIN_TIMEOUT, an error will occur when the client fails to receive a response within the set period. The error can also occur when you have network problems.
Page -34
Note If the server machine is up and running, but the server is not, you get a different error. If no server is listening on the specied port, the server machine signals the client, via a network error, that the connection cannot be formed. The connection fails regardless of the CS_LOGIN_TIMEOUT value. See the section Call to connect two endpoints failed for information about this error.
Action Check your application to see if the timeout period set is appropriate for you. You can code your application to trap the error and wait for multiple timeout periods, or to cancel the command that got the error and continue with the rest of the processing. You can call ct_con_props with the CS_LOGIN_STATUS property to determine if the error was caused by a login timeout or during a command processing. A value of CS_TRUE means that the server timed out during command processing. The following code illustrates how to trap a timeout error on a command, and one way to handle the error:
.... if (CS_NUMBER(client_msgtxt->msgnumber) == 63 ) { printf("A TIMEOUT ERROR OCCURRED. Please choose "); printf("one of the following options:\n"); printf("1. Cancel only this command and continue \ processing. \n"); printf("2. Wait for another timeout period. \n"); printf("\n\n Enter choice: "); scanf("%d",&ans); if ( ans == 1 ) { retcode = ct_cancel(conn, NULL, CS_CANCEL_ATTN); if (retcode == CS_SUCCEED ) printf("Command cancelled! ..\n"); /* You must return CS_SUCCEED from the ** callback, otherwise the connection will be ** marked dead. */ return CS_SUCCEED ; } else if ( ans == 2 )
Page -35
{ printf("Waiting for another timeout period \n"); return CS_SUCCEED ; } } ....
See the Open Client Client-Library/C Reference Manual section on Handling Timeout Errors for more details. If you do not wish to wait for locks to be released on the server and wish to allow dirty reads, you can set the transaction isolation level to 0. You can set this option using ct_command with the command buffer:
set transaction_isolation level 0
Alternatively, call ct_options and set the buffer to CS_OPT_LEVEL0. See the Adaptive Server Enterprise Performance and Tuning guide for details and cautions on the use of transaction isolation levels.
x WARNING! Isolation level 0 allows transactions to read uncommitted data and should only be used when the accuracy of your read is not an issue.
For login timeout errors, check the interfaces le entry for this server to get the machine name, than issue a telnet to that machine to see if it up and running. Check with your network administrator to see if there are any network problems. Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -36
Connection has been marked dead

Message Text
Number: (50) Severity (1) Layer (1), Origin (1) text: ct_xxxxx: user api layer: external error: The connection has been marked dead.
where ct_xxxxx is the rst API to be called in the application after the connection has been marked dead. Possible Cause The most common reason for a connection to be marked dead is a return code of CS_FAIL from the Client-Library or server message callback routines. Even when the application does not explicitly return a CS_FAIL from the error callback routines, Client-Library can return a CS_FAIL if it does not t nd enough memory to allocate for the error. This is a rare occurrence, but it is possible even if you use inline error handling (ct_diag) in place of callbacks. Action To resolve the problem, take following actions as appropriate: Check your Client-Library and server error callback routines and verify that they always return CS_SUCCEED. If you are using inline error handling and a timeout error occurs, by default, Client-Library does not retry the read and marks the connection dead. To make Client-Library retry the read, set the CS_DIAG_TIMEOUT property to CS_FALSE. If you use callbacks, Client-Library retries the read on timeout errors as long as the callback routine returns CS_SUCCEED. If the connection has been marked dead because of a result processing error, try calling ct_cancel with a type of CS_CANCEL_ATTN or CS_CANCEL_ALL to revive the connection. If this fails, the application must close the connection and drop its CS_CONNECTION structure. Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -37
CS_IODESC only for text or image columns

Message Text
Number: (97) Severity (1) Layer (1) Origin (1) text: ct_data_info(GET): user api layer: external error: A CS_IODESC can only be retrieved for text or image columns. Column %1! is not a text or image column.
Possible Cause The application is making a call to ct_data_info to retrieve a CS_IODESC for a non-text or non-image column. The CS_IODESC structure describes text or image data only. Action Check the column number specied in the ct_data_info call and verify that it is a text or image column. To do this, log into the server with isql and enter:
sp_help table_name
Compare the column information with your select statement to verify that the column you are selecting is a text or image column. Then compare the position of the column in the select statement with the column number in the ct_data_info call. The column number in the ct_data_info call is the position of the item in the select statement, not in the table. For example, the BIGTABLE table is dened as:
create table BIGTABLE (item_no int, item varchar(255), descr image, notes text)
The select statement in the application is:

SELECT item_no, notes, descr from BIGTABLE
You can make a ct_data_info call only on columns 2 and 3, but not on column 1, which is of integer type, as shown here:
Page -38
CS_COMMAND *cmd; CS_IODESC *des; ... retcode = ct_data_info(cmd, CS_GET, 2, &des); ... retcode = ct_data_info(cmd, CS_GET, 3, &des); ...
Page -39
CS_IODESC cannot be retrieved

Message Text
number (98) severity (1) layer (1), origin (1) text: ct_data_info(GET): user api layer: external error: A CS_IODESC cannot be retrieved for a column that has not been read. Column %1! has not been read.
Possible Cause Before the application makes a call to ct_data_info to retrieve the I/O descriptor for a text or image column, it must rst select the column and row by making a call to ct_get_data. The above error occurs when you skip this step. Action To resolve the problem, verify that your application does the following: Makes a call to select the column and row, where the column is the text or image column to be updated and the row, selected by the WHERE CLAUSE, is the row in which the text or image column is to be updated. Calls ct_fetch to fetch the row. Calls ct_get_data to retrieve the columns value and refresh the I/O descriptor. If you wish, you can refresh the I/O descriptor without getting the column value by setting the buen parameter to 0. Calls ct_data_info to retrieve the I/O descriptor into the CS_IODESC structure. The following code fragment illustrates this:
..... CS_RETCODE retcode; CS_COMMAND *cmd; CS_IODESC des; ..... ct_command( ...., "select intcol, image_col from tablex", ....); ..... /* Retrieve and display the results. */ while(((retcode = ct_fetch(cmd, CS_UNUSED, CS_UNUSED, CS_UNUSED, &count)) == CS_SUCCEED)
Page -40
|| (retcode == CS_ROW_FAIL) ) { ..... /* Refresh the I/0 descriptor retcode = ct_get_data(cmd, 2, ..... /* Retrieve the descriptor of ** It is available only after */ been fetched.
for the image col */ Data, 0, NULL); the image data. the column has
retcode = ct_data_info(cmd, CS_GET, 2, &des); ..... } .....
See the Open Client Client-Library/C Reference Manual section on text and image Data Handling and the reference pages for ct_get_data and ct_data_info for more details. See also the sample program getsend.c, which comes with the Open Client/C product. The sample is located in the $SYBASE/sample/ctlibrary directory. This is a complete ClientLibrary program that shows how to retrieve and update text or image data. Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -41
CS_IODESC structure must be set

Message Text
number (92) severity (1) layer (1), origin (1) text: ct_send_data(): user api layer: external error: A CS_IODESC structure must be set with ct_data_info() before ct_send_data() can be called.
Possible Cause The I/O descriptor contains the text pointer and timestamp value that the server uses to manage updates to text and image columns. Before a call is made to send the new value for the update, the application must dene the size of the new value in bytes and indicate whether the server should log the update. The server uses this information to update the requested text or image column. The error occurs when this information is not available at the time of the ct_send_data call. Action Check your code and ensure that ct_data_info is being called to set the I/O descriptor before calling ct_send_data. Verify that your application does the following before sending the new value for the update: Calls ct_command to initiate a command for the update. Modies the I/O descriptor as required. Usually, you only need to modify the total_txtlen and possibly the log_on_update elds. Calls ct_data_info to set the I/O descriptor for the column to be updated. After performing these steps, call ct_send_data to write the new value. The following code fragment illustrates this sequence:
..... CS_RETCODE retcode; CS_COMMAND *cmd; CS_IODESC des; CS_TEXT *txtptr; CS_INT txtlen; ..... /* Inform Client-Library the next data sent will be ** used for a text or image update. */ retcode = ct_command(cmd, CS_SEND_DATA_CMD, NULL, CS_UNUSED,
Page -42
CS_COLUMN_DATA); ..... /* Fill in the description information for ** the update and send it to Client-Library. */ txtptr = (CS_TEXT *)"This is the new update value"; txtlen = strlen((CS_CHAR *)txtptr); des.total_txtlen = txtlen; des.log_on_update = CS_TRUE; retcode = ct_data_info(cmd, CS_SET, CS_UNUSED, &des); ..... /* Check retcode status */ retcode = ct_send_data(cmd, txtptr, txtlen); .....
See the Open Client Client-Library/C Reference Manual section on text and image Data Handling and the reference pages for ct_data_info and ct_send_data for more details. Also see the sample getsend.c, which is shipped with the Open Client/C product. The sample is in the $SYBASE/sample/ctlibrary directory. This is a complete Client-Library program that shows how to retrieve and update text or image data. Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -43
Bytes exceeds the amount specied

Message Text
Number: (93) Severity (1) Layer (1) Origin (1) %1! bytes exceeds the amount of bytes specified for this send data operation. Only %2! more bytes can be sent.
Possible Cause The error occurs when the application calls ct_send_data to send to the server text or image data whose size in bytes is greater than the value specied in the total_txtlen eld of the CS_IODESC structure. For example, if you wish to send text data whose size is 38 bytes, but the application is coded like the fragment below, you will get a runtime error:
.... CS_INT txtlen; CS_IODESC des; CS_TEXT *textdata; CS_CHAR *newdata; .... strcpy(newdata,"This is the new text value for update."); txtlen = strlen((CS_CHAR *)textdata); des.total_txtlen = 10; retcode = ct_data_info(cmd, CS_SET, CS_UNUSED, &des); .... /* Check retcode value */ retcode = ct_send_data(cmd, newdata, txtlen); .... /* Check retcode value */ retcode = ct_send (cmd); ....
The error occurs because the total_txtlen eld in the CS_IODESC contains the value 10, but the actual data being sent to the server is 38 bytes, the value of txtlen. Action Check your code for the value of the total_txtlen eld of the CS_IODESC structure. Compare this with the length specied in the ct_send_data call. You can choose to send all the data in one chunk or break up the data and call ct_send_data in a loop until all of the data has been sent to the
Page -44
server. If all of the text or image data is being sent in one chunk, the length specied in the ct_send_data call must be equal to the value specied in the total_txtlen eld. All the data must be sent to the server, either in one or multiple chunks, before the ct_send command signals the end of the update. The example can be corrected as follows:
..... strcpy(newdata,"This is the new text value for update."); txtlen = strlen((CS_CHAR *)textdata); des.total_txtlen = txtlen; retcode = ct_data_info(cmd, CS_SET, CS_UNUSED, &des); .... /* Check retcode value */ retcode = ct_send_data(cmd, newdata, txtlen); .... /* Check retcode value */ retcode = ct_send (cmd); ....
See the Open Client Client-Library/C Reference Manual page on ct_send_data for more details, including a code sample that calls ct_send_data in a loop to send data in chunks. The complete sample can be found in getsend.c located in your $SYBASE/sample/ctlibrary directory. Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -45
Bytes specied have not been sent

Message Text
Number: (94) Severity (1) Layer (1), Origin (1) text: ct_send(): user api layer: external error: The number of bytes specified for this send data operation have not been sent. %1! more bytes need to be sent.
Possible Cause The application has called ct_send to write text or image data to the server before ct_send_data sent all the bytes specied in the total_txtlen eld of the CS_IODESC structure. For example, if you wish to send text data whose size is 38 bytes, but the application is coded like the fragment below, you will get a runtime error:
CS_INT txtlen; CS_IODESC des; CS_CHAR *newdata; .... strcpy(newdata,"This is the for update."); txtlen = strlen(newdata); des.total_txtlen = 100; retcode = ct_data_info(cmd, CS_UNUSED, &des); .... /* Check retcode value retcode = ct_send_data(cmd, txtlen); .... /* Check retcode value retcode = ct_send (cmd); ....
new text value
CS_SET, */ (CS_TEXT *)newdata, */
The error occurs because the total_txtlen eld in the CS_IODESC contains the value 100, but the actual data being sent to the server is 38 bytes, the value of txtlen. Action Check your code for the value of the total_txtlen eld of the CS_IODESC structure. Compare this with the length specied in the ct_send_data call. You can choose to send all the data in one chunk or break up the data and call ct_send_data in a loop until all of the data has been sent to the
Page -46
server. If all of the text or image data is being sent in one chunk, the length specied in the ct_send_data call must be equal to the value specied in the total_txtlen eld. All the data must be sent to the server, either in one or multiple chunks, before the ct_send command signals the end of the update. The example can be corrected as follows:
..... strcpy(newdata,"This is the new text value for update."); txtlen = strlen((CS_CHAR *)textdata); des.total_txtlen = txtlen; retcode = ct_data_info(cmd, CS_SET, CS_UNUSED, &des); .... /* Check retcode value */ retcode = ct_send_data(cmd, newdata, txtlen); .... /* Check retcode value */ retcode = ct_send (cmd); ....
See the Open Client Client-Library/C Reference Manual page on ct_send_data for more details, including a code sample that calls ct_send_data in a loop to send data in chunks. The complete sample can also be found in getsend.c located in your $SYBASE/sample/ctlibrary directory. Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -47
ID already exists on connection

Message Text
Number: (134) Severity (1) Layer (1), Origin (1) text: ct_dynamic(PREPARE): user api layer: external error: The specified id already exists on this connection.
Possible Cause Every Dynamic SQL call made by Client-Library has a statement identier. The identier name is specied by the application during a call to ct_dynamic with CS_PREPARE as the action type. The id, or identier parameter, for this call must be unique so that the statement can be identied by the server and application. If you call ct_dynamic with CS_PREPARE as the action type and id set to an existing identier name, you get this error. Action To resolve the problem, take one of the following actions as appropriate: If you are using multiple prepare statements in your application, check the id parameter of each ct_dynamic call with an type of CS_PREPARE to be sure that you are using a unique id parameter for every statement on a given connection. If you want to use the same id for a second CS_PREPARE call, deallocate the rst Dynamic SQL statement by calling ct_dynamic with type CS_DEALLOC. Verify that the call returns CS_SUCCEED.
Note Each prepared SQL statement is a temporary stored procedure, compiled and stored by the server until it is explicitly deallocated or the connection is closed. Applications make connection requests quickly, and a new connection might make a request for an id before the server has cleaned up a previous connection for that id. Therefore, you may want to explicitly deallocate statements rather than relying on the server to do it for you.
If your application is already making a call to deallocate the prepared statement before issuing a new one with the same id, verify that the statement has been deallocated by the server. Page -48 Client Library Error Messages
Because dynamic objects are temporary, the stored procedure is created in the tempdb database. Log into the server with isql and issue the following query:
1> use tempdb 2> go 1> select name from sysobjects 2> where name like identifier_name 3> go
The following example shows how this works. The call to prepare a statement looks like this:
.... retcode = ct_dynamic(cmd_ptr, CS_PREPARE, "d_insert", strlen("d_insert"), insert_statement, CS_NULLTERM); RETURN_IF(retcode, "ct_dynamic: prepare failed"); ....
The id for the prepared statement is d_insert. To see if this statement was deallocated, log into the server and issue the following query:
1> select name from tempdb..sysobjects 2> where name like %d_insert% 3> go
If the statement is not deallocated, you see this output:

name -----------------------------#P$$000010022629487_d_insert (1 row affected)
All Dynamic SQL statement names in the server begin with a # (pound sign), which denotes a temporary object. The id supplied by the application appears at the end of the string. If possible, restart the server to remove these objects.
Note An incomplete cleanup can occasionally be the result of a bug. If you have checked your application and veried that the error is not in the application code, or you have restarted the server and the problem returned, call Technical Support.
Page -49
Page -50
ID does not exist

Message Text
Number: (135) Severity (1) Layer (1), Origin (1) text: ct_dynamic(EXECUTE): user api layer: external error: The specified id does not exist on this connection.
Possible Cause Every Dynamic SQL call made by Client-Library has a statement identier. The identier name is specied by the application during a call to ct_dynamic with CS_PREPARE as the action type. This error occurs when an invalid id is used by a call to ct_dynamic of type CS_EXECUTE, CS_DESCRIBE_INPUT, CS_DESCRIBE_OUTPUT or CS_DEALLOC. An invalid id can result when: You fail to specify a statement id in a call to ct_dynamic of type CS_PREPARE before calling ct_dynamic of type CS_EXECUTE, CS_DESCRIBE_INPUT, CS_DESCRIBE_OUTPUT, or CS_DEALLOC. A ct_dynamic call uses a name different than the one specied in the CS_PREPARE. Names are case sensitive. The length parameter of the identier is incorrect. The prepared Dynamic SQL statement has already been deallocated. Action To resolve the problem, take the following actions: Verify that you are making a call to ct_dynamic with a type of CS_PREPARE and that you are creating the Dynamic SQL statement correctly before making a call to execute the statement, describe input or output data, or deallocate the statement. Verify that the idlen parameter passed to every ct_dynamic call (including CS_PREPARE) is accurate. Use a strlen of the identier or CS_NULLTERM. Verify that the ct_dynamic calls are made on the same connection as the one on which the statement was created. Also check to see that the connection still exists, since the prepared statement is automatically dropped by the server when that connection to the server is closed.
Page -51
Page -52
Page -53
Sticky binds do not match result set

Message Text
Number: (184) Severity (0) Layer (1), Origin (1) text: ct_results(): user api layer: external error: The sticky binds do not match the current result set. The sticky binds have been discarded for all result sets.
Possible Cause If an application sets the command property CS_STICKY_BINDS to TRUE, Client-Library preserves all bindings for all result sets returned by the rst execution of a command. It then uses these bindings for future executions of the same command within the application. After each execution of the command, a call to ct_results compares the current result format to that saved earlier. If ct_results nds a mismatch, it displays this warning and clears all bindings. ct_results returns CS_SUCCEED, as this is only an informational error message. Result formats for the same command can only vary if one of these conditions exists: The SQL statement or stored procedure contains conditional server-side logic, such as an if or while clause. The denition of the stored procedure changes during multiple executions of the command. The table denition changes during multiple executions of the command. For example, this command:
select * from table_name
could return varying result sets if the table denition changes between iterations of the command. Action To resolve the problem, take the following actions: Log on to the server with isql and check to see if the denition of the stored procedure or table has changed between iterations. To get the table or procedure denition, issue one of these commands:
1> sp_help table_name 2> go
Page -54
or:
sp_helptext procedure_name 2> go
If the denitions have not changed, check the logic of the SQL statement or stored procedure text. Are there conditions under which a different row format could be returned? If this is true, change the select list so that the results are in the same format as the rst row that is retrieved from the rst execution of the command. If the row formats are not guaranteed to be the same in your scenario, do not use the CS_STICKY_BINDS feature. Versions in Which This Error Is Raised Client-Library 11.x and later.
Page -55
Error while binding to directory service

Message Text
Number: (1) Severity (5) Layer (6), Origin (8) text: ct_connect(): directory service layer: internal directory control layer error: There was an error encountered while binding to the directory service.
Possible Cause Client Library 11.x provides alternatives to a Client-Library application for looking up an Adaptive Server, SQL Server, or Open Server. In past versions, Sybase clients located the server they wished to connect to by looking up the network address in the interfaces le, called sql.ini on PC platforms. With version 11.x, Client-Library supports other directory services such as DCE. A directory service manages the creation, modication, and retrieval of information about network entities. Client-Library 11.x applications can use this service as an alternative to the interfaces le to obtain information about servers. By default, a Client-Library application attempts to locate the server via the interfaces le. However, if the libtcl.cfg le, located in the $SYBASE/cong (UNIX, VMS) or SYBASE/ini (NT) directory, lists another directory service, Client-Library attempts to use that directory service. If that service does not exist or can not be located in the specied location, this error occurs. The error also occurs if the interfaces or sql.ini le can not be located. Action Take one of the actions described in the following sections. If you are using the interfaces or sql.ini le If your application uses the standard mode of locating servers, the interfaces le, verify that your SYBASE variable is pointing to the correct location for your Sybase directory. By default, Client-Library applications look for a le called interfaces or sql.ini in the directory pointed to by the SYBASE environment variable. If SYBASE has not been set, at connect time Client-Library will look for a le called interfaces in the home directory of the sybase user. If you wish to use an interfaces le from a different location, your Client-Library application must call ct_cong to set the CS_IFILE property. This property allows you to specify the location of the Page -56 Client Library Error Messages
interfaces le that you wish to use for this application. For example, if you wish to use the interfaces le from the directory /usr/u/sybase11, you might code your application as follows:
.... CS_CONTEXT*cntx_ptr; CS_RETCODEretcode; .... retcode = ct_config( *cntx_ptr, CS_SET, CS_IFILE, "/usr/u/sybase11/interfaces", CS_NULLTERM, NULL ); ....
If you wish to use the interfaces le from the SYBASE directory and have veried that the variable is pointing to the correct location, check your libtcl.cfg le located in the cong or ini subdirectory under SYBASE. Depending on your operating system, you will see a line similar to:
[DIRECTORY] ;dce=libddce.so ditbase=/.:/subsys/sybase/dataservers
The word DIRECTORY within square brackets denotes the directory services section of the libtcl.cfg le. The semicolon (;) denotes a comment. In this example, the dce directory service entry is commented out, as it should be when you use the interfaces le. If your entry is not commented out with a semicolon as in the example, add a semicolon before the entry. If you are using DCE services If you are using DCE services, you can get the error when the DCE directory service entry can not be located in the directory services section in the libtcl.cfg le. Edit the entry in the libtcl.cfg le to point to your DCE service. Refer to the Open Client/Server Conguration Guide for your platform for details on conguring DCE entries. A directory service can also be specied from within the ClientLibrary application by setting the CS_DS_PROVIDER property in the ct_con_props call. See the Open Client Client-Library/C Reference Manual chapters on Directory Services and Properties for more information.
Page -57
Note Client-Library falls back to the interfaces le to obtain the servers address if any of the following are true: - The le libtcl.cfg does not exist in the cong or ini subdirectory. - There are no uncommented entries in the [DIRECTORY] section of the libtcl.cfg le. -The specied directory driver exists but fails to load.
See the Release Bulletin for your platform to nd out which directory services Sybase supports. To nd out which directory services your platform supports, contact your System Administrator or your operating system documentation or vendor. Versions in Which This Error Is Raised Client-Library 11.x and later.
Page -58
Attempt to load protocol driver failed

Message Text
Number: (4) Severity (5) Layer (5), Origin (3) text: ct_connect(): network packet layer: internal net library error: Attempt to load protocol driver failed
Possible Cause This error occurs when Client-Library cannot load the network driver because the Net Library driver doesnt exist or you have specied an incorrect driver. The Sybase network library, Net Library, interacts with the network at the operating system level. Only certain drivers are supported on specic platforms. See the Open Client/Server Conguration Guide for your platform for platform-specic drivers. Action To resolve the problem, rst verify that you have the correct network library for your platform and version: If you have Client-Library 10.0.x, check the $SYBASE/lib directory to verify that you have the right network library and that the drivers are correctly linked. Network transport drivers include:
Driver
libtli.so or libtli.a for tli libinsck.sl or libinsck.a for tcp libinsck.so.a or libinsck.a for tcp
Platform
Sun Solaris HP 9000 RS/6000
Client-Library 11.x supports dynamic loading of Net-Library services. This allows you to change the driver that an application uses and to use features as they become available without relinking the application. Client-Library 11.x looks in the [DRIVERS] section of libtcl.cfg to determine which network driver to load. This le is located in the $SYBASE/cong directory. See the Open Client/Server Conguration Guide for your platform for a
Page -59
list of valid network protocols and instructions on adding or modifying a network driver. Network transport drivers include:
Driver
libtli.so for tli libinsck.sl for tcp libinsck.so.a for tcp
Platform
Sun Solaris HP 9000 RS/6000
Note 11.x only provides for dynamic loading of the Net- Library drivers, whereas 10.x provided a statically linked version of the driver as well.
This element must match the protocol of the driver. For example, you cannot use a tcp protocol with a tli driver. See the Open Client/Server Conguration Guide a complete list of driver/protocol mappings for UNIX and desktop platforms. Example The following example shows how to correct the error in the ibtcl.cfg le. You can nd this le in the $SYBASE/cong or SYBASE/ini (NT) directory. In this example, the error occurs because you are using the standard Sybase 11.x non-threaded libraries, or isql or bcp 11.x, but your DRIVER entry in the libtcl.cfg le reads:
[DRIVERS] ;libtli.so=tcp unused ; This is the non-threaded tli driver. libtli_r.so=tcp unused ; This is the threaded tli driver.
You have incorrectly specied the threaded tli driver, which is incompatible with the other non-threaded libraries used to build your application or with the standard utilities that have been statically linked with the non-threaded libraries. You can correct the error by commenting out the threaded driver entry by placing a ; (semicolon) in the rst column, so that the entry reads:
;libtli.so=tcp unused ; This is the non-threaded tli driver. ;libtli_r.so=tcp unused ; This is the threaded tli driver.
By default, both lines under the [DRIVERS] section are commented, so that the application uses the default driver listed
Page -60
in the table. Commenting both lines is the same as uncommenting the non-threaded driver line. Versions in Which This Error Is Raised Client-Library 10.0.x and later.
Page -61
Page -62
DB-Library Error Messages

This chapter includes information on common error messages returned by DB-Library. All DB-Library error messages have numbers and severity levels. Error numbers and severity levels have corresponding key words dened in DB-Library; these appear next to the numbers in this chapter. For example, the following entry: Error Number 20009 (SYBECONN) means that you can use the key word SYBECONN in your programs to identify Error 20009.
4.
For a listing of all DB-Library errors, including number and severity, see the les sybdb.h and syberror.h in the SYBASE/include directory.
Page -1
SQL Server connection timed out

Error Number 20003 (SYBETIME) Severity 6 (EXTIME) Message Text
SQL Server connection timed out.
Possible Cause This error occurs when the number of seconds specied by a DBLibrary application for the server to send back results has elapsed. Usually, the server sends back results immediately after processing a query. However, it is possible that a resource required by the application is locked by another connection to the database. If no timeout interval is set by the application, it will wait indenitely until the lock is released. Action To resolve the problem, take the following actions as appropriate: By default, DB-Library will wait indenitely for results. The routine dbsettime lets you specify a timeout period. You can then code the error handler to retry the timed-out command, cancel it and proceed with the rest of the processing, or exit the application by closing the DBPROCESS. See the page for dberrhandle in the Open Client DB-Library/C Reference Manual for various codes that can be returned when you get a timeout error. You can use dbsqlsend to send a command to the server rather than dbsqlexec. After sending a query to the server, dbsqlexec waits until a response is received or until the timeout period has elapsed. However, using the sequence dbsqlsend, dbpoll and dbsqlok instead of dbsqlexec lets your application respond more effectively to multiple input and output streams so it can do other things while waiting for the server to return results. See the page on dbsqlok in the Open Client DB-Library/C Reference Manual for an example. Try to minimize timeouts in general by completing transactions quickly. Keeping a transaction open until the end of an
Page -2
application will cause locking issues for other users who need to access the same tables. To see which connection is blocking your query, log on to the server with isql and issue the command sp_who. The output column blk shows you which spid is causing the problem. The command sp_lock tells you what kind of locks are being held on the table. Contact your Sybase system administrator to help identify the user and process causing the block. If your application is the one blocking itself, check your code and see if you have an open transaction on a different connection which occurs prior to the blocked command and which uses the same tables. If so, have the rst transaction complete before issuing the second command, or try to issue the commands on the same connection. See Error 20019, Results pending, for an example. For reads, if you do not want to wait for locks to be released and are willing to get dirty readsthat is, reads of data that may be in the process of changingyou can set the transaction isolation level to 0. You can set this option by issuing this command:
set transaction_isolation level 0
See the section on transaction levels in the Adaptive Server Enterprise Reference Manual for complete information on the various isolation levels.
x WARNING! Using isolation level 0 may cause you to read inconsistent data.
Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -3
Read from SQL Server failed

Error Number 20004 (SYBEREAD) Severity 9 (EXCOMM) Message Text
Read from SQL Server failed.
Possible Cause This error occurs when the server does not respond to the clients request for communication, for instance when the server is down or hung, or there is a network problem. This error can only occur after a connection has already been established. For example, if you make a SQL request to the server, but the server is shut down before it can return results, DB-Library raises the error and marks the DBPROCESS making the request as dead, making the structure unusable for any future requests. The following example illustrates the general timing of this error. In the example, the DBPROCESS is valid when a SQL request goes to the server, but the server or the network goes down before the server can return results:
..... DBPROCESS *dbproc; ..... /* Frame the sql command. */ dbcmd(dbproc, "select * from publishers "); ..... /* Send the command to the server but don't ** wait for a response. */ if (dbsqlsend(dbproc) == FAIL) ..... /* Check for results from the server with dbsqlok. ** If successful, process results with dbresults. ** If a network error occurs or the server goes ** down at this point, dbsqlok returns FAIL and ** the program calls the installed error handler. */ if (dbsqlok(dbproc) == FAIL) .....
Page -4
Action To resolve the problem, take the following actions as appropriate: Code your error handler as in the following example:
int err_handler(dbproc, severity, dberr, oserr, dberrstr, oserrstr) ..... { if ((dbproc == NULL) || (DBDEAD(dbproc))) { printf("DBPROC is dead or null. This dbprocess will be killed. \n"); return(INT_EXIT); else /* Print errors and return INT_CANCEL */ ..... }
If the DBPROCESS has been marked as NULL, you have to reestablish your connection to the server. Check to see whether the server went down unexpectedly. You may also see the accompanying error Unexpected EOF from SQL Server. Check for corresponding errors in the server log. Have your network administrator check for possible network issues. If the error usually seems to occur after the execution of a particular query, check the server log for the SQL causing error. If you believe the problem is caused by a SQL command but are not sure which one, make a call to dbrecftos in your application to record all SQL sent to the server. See the error General SQL Server error in this manual for an example using dbrecftos. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -5
Unable to open socket

Error Number 20008 (SYBESOCK) Severity None Message Text
Unable to open socket.
Possible Cause The following are the most common causes of this error: The error can occur when you call dbopen if a lack of operating system resources prevents DB-Library from opening a connection. It is usually accompanied by an operating system error, such as the following UNIX error:
OS error 24: too many files open.
This error is dened as EMFILE in the /usr/include/sys/errno.h le on most UNIX operating systems. It might occur if your application leaves a lot of connections open at the same time, causing the operating system to run out of le descriptors. The error might occur because the operating system thinks that you are trying to bind to an address that is already in use. This can happen if you have an application that opens and closes many connections very quickly. Although you may have called dbclose to close a connection, the operating system may not have yet released that resource for reuse. The error can be caused by an invalid interfaces le entry for the server your application is attempting to connect to. Invalid interfaces le entries can cause several errors, but in this case, the error is due to an incorrect network address. For a similar error, see Error 1605 in the Adaptive Server Enterprise Troubleshooting and Error Messages Guide. Action To resolve the problem, take the following actions as appropriate:
Page -6
Reduce the number of simultaneous connections in your application. You may need to close connections when they are not being used and reopen them later. If you cannot decrease the number of simultaneous connections opened by your application, increase the number of le descriptors at the operating system level. This will increase the number of connections that you can open in your application. First check the current value of the soft and hard le descriptor limits. To check the soft limit, which is congurable by the user, type one of the following commands at the UNIX operating system prompt:
% limit descriptors (C shell) $ ulimit -n (Bourne shell)
To display the current hard limit, the maximum value congured by the operating system administrator, type one of the following commands at the operating system prompt:
% limit -h descriptors (C shell) $ ulimit -Hn (Bourne shell)
To increase the soft limit on UNIX, type the following command at the operating system prompt:
% limit descriptors n (C shell) $ ulimit -S n new_value (Bourne shell)
where n is the current value for the soft limit, and new_value is the value to which you want to increase the soft limit.
Note You can use Sybase CentralTM to read the o/s le descriptors parameter, which tells you how many le descriptors have been allotted by the operating system to Adaptive Server, but you cannot use this tool to change the parameters value.
If you are getting system errors indicating that addresses are already in use, for example, on VMS with Pathworks, check with your system administrator to see whether you can congure system parameters so that the operating system releases sockets with no delay. You can also try adding a small delay after every dbclose call.
Page -7
If you get the error on the very rst call to dbopen, then the problem is probably in the interfaces le. Be sure to use a Sybasesupplied tool such as sybinit, for pre-11.x releases, or dsedit, for Open Client 11.x, to make entries to the interfaces le. Do not copy an interfaces les from another machine, especially one with a different operating system, as the network protocol could be different. If the client is on a different machine than the server, create the interface entry on the client machine. See the section Related Interfaces File Errors in the writeup for the error SQL Server is unavailable or does not exist Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -8
SQL Server is unavailable or does not exist

Error Number 20009 (SYBECONN) Severity 9 (EXCOMM) Message Text
Unable to connect: SQL Server is unavailable or does not exist.
Possible Cause This error is raised when connection to the server has failed, or, the current DBPROCESS is dead. Possible reasons include: The Server is not running. The error can occur if the server is not running at the start of the application, when it makes a dbopen call, or if the server goes down later and the application makes a call to connect. The application requests an incorrect server name. The server name can be the value of the DSQUERY environment variable or it can be specied in the application's dbopen function call. The interfaces le contains incorrect server information. The SYBASE environment variable does not point to the correct interfaces (UNIX) or sql.ini (NT) le. Action To resolve the problem, take the following steps: 1. Check whether the server is still running. On UNIX platforms, use the showserver command:
$SYBASE/install/showserver
On NT, check the console for the server process. Or simply try connecting to the server. Restart the server if necessary. 2. If your DB-Library program does not explicitly set the name of the server that you wish to connect to in the dbopen call, DBLibrary uses the value of the DSQUERY environment variable. Verify that this variable is set to the correct server name. For example, on UNIX platforms, issue the command:
Page -9
% echo $DSQUERY
To set the value, issue the command:

% setenv DSQUERY server_name
where server_name is the correct name of your server. 3. Check the program to see if it explicitly requests a server as part of the dbopen call. Look for an entry like this:
dbopen(dbproc, "SYBASE");
Verify that the server name is correct. If you want the application to use the value of DSQUERY instead, change the dbopen call to:
dbopen(dbproc, NULL); Note If you do not set the server name in the program or DSQUERY environment variable, DB-Library looks for a server named SYBASE.
4. DB-Library uses the interfaces le to locate the server requested. If you are sure that the server name is correct, verify that the application can nd the correct path to the interfaces le: - Check the SYBASE environment variable. It should point to the directory where your current version of the software is installed. Verify that the interfaces le exists in this directory. - Check the application for a dbsetile command. This command tells the application to look for the interfaces le in an alternate location. If this command exists in the application, verify that the interfaces le can be found in this path. 5. Check the information contained in the interfaces le to verify that the following information is correct: - Server name - Machine name - Port number
Note The UNIX commands given in this section are C-shell (csh) commands. If you are using a different UNIX shell check your operating system documentation for the appropriate commands.
Page -10
Related Interfaces File Errors Other error messages referring to problems with the interfaces le include the following: Network information for a server is not formatted correctly with tabs or is in the wrong format for the network protocol:
Severity: 2, Error No: 20055. Unknown network type found in interface file.
Server name is not listed in the interfaces le:

Severity 2, Error No: 20012. Server name not found in interface file.
The interfaces le does not exist at the location where the application looked for it:
Severity: 3, Error No: 20015. Could not open interface file.
See the installation guide for your platform for instructions on how to enter a server in the interfaces le. Sybase conguration tools such as sybinit or sybsetup can help you perform this task. See Step 4 in the previous section for information on locating the interfaces le. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -11
Maximum dbprocesses already allocated

Error Number 20011 (SYBEDBPS) Severity 8 (EXRESOURCE) Message Text
Maximum number of dbprocesses already allocated.
This error occurs during a dbopen call when an application tries to open a DBPROCESS that would exceed the maximum number of DBPROCESSes allowed. The maximum by default is 25, but you can set a maximum value in the application using dbsetmaxprocs. This limit applies to the application session; it is not the maximum number of users that the server is congured for. Action To resolve the problem, take the following actions as appropriate: Check the application source code to see if dbsetmaxprocs has been set. Then check the code to see if the number of connection requests exceeds the value of dbsetmaxprocs, if set, or the default value of 25. If the value of the dbsetmaxprocs is smaller than the number of connection requests, or if it is missing, set the value to a number large enough to accommodate the connection requests by calling:
dbsetmaxprocs(maxprocs)
Change the code to reuse or close some connections.

Note A different error is raised when the number of connections attempted is more than the number of users the server is congured for. See Net-lib operation terminated due to disconnect in Chapter 3, Client Library Error Messages for information on what to do if you exceed maximum server connections.
Page -12
Page -13
Unexpected EOF from SQL Server

Error Number 20017 (SYBESEOF) Severity 9 (EXCOMM) Message Text
Unexpected EOF from SQL Server
Possible Cause This error can be caused by either of the following events: The server that the DB-Library application is connected to goes down. The server process (spid) corresponding to the client connection in the server dies. Action To resolve the problem, take the following actions as appropriate: Try to reconnect to the server. If you get this message:
20009 "SQL Server is unavailable or does not exist"
check to see whether the server process is still running. On UNIX systems, you can use the command:
showserver
On NT, check the console, or simply try connecting to the server. If the server is not running, check the server error log and try restarting. If the connection attempt is successful, then the problem occurred when the spid for the previous connection stopped. Troubleshoot the problem. To nd out which SQL statement was executing when the connection went down, add the following command to your code before the rst call to dbcmd:
dbrecftos(file_name); dbrecftos writes the program's SQL statements as they execute to the output le designated by le_name. Connect to the server
Page -14
with isql and individually issue the nal statements recorded in the le to see if they cause the error. If you have a Solaris 2.4 or 2.5.x operating system, you may be experiencing a problem caused by Solaris Bug 1233973 or 1233827. These bugs in the Solaris tcp/ip code cause the server to receive a spurious disconnect signal from the client. As a workaround, you can try increasing the operating system parameter tcp ip abort interval, using this command:
% ndd -set /dev/tcp tcp_ip_abort_interval new_value
where new_value is a value higher than the default of 480000, for example, 960000. Patches containing the x for this problem are available from Sun. The following table lists patch numbers for Solaris 2.4, 2.5, and 2.5.1:
Table 4-1: Patches available from Sun Patch Versions Area Affected 2.4
101945-44 101945-44
Bug ID
1233973 1233827
2.5
103169-06 103447-03
2.5.1
103630-01 103582-01 /kernel/drv/ip /kernel/drv/tcp
See TechNote 2530 for more details about this bug. TechNotes are posted in Sybase Technical Library on the Web at http://techinfo.sybase.com. Solaris systems can also be affected by the values of the following tcp parameters: - tcp_rexmit_interval_max - tcp_ip_abort_interval If the tcp_rexmit_interval_max parameter is too high with respect to the tcp_ip_abort_interval, you can experience the disconnect problem. Generally, you can use a tcp_rexmit_interval_max value equal to one third the tcp_ip_abort_interval value. Contact your system administrator or Sun technical support for the optimal values in your environment. Background: This workaround is based on Suns polling algorithm. An internal tcp parameter, tcp_timer_backoff, determines how often a poll of the tcp window occurs. The value
Page -15
of tcp_timer_backoff is initially set to the value of tcp_rexmit_interval_initial. However, if there is no room in the tcp window to send data when a poll occurs, tcp_timer_backoff doubles its value at each succeeding poll, up to the value of tcp_rexmit_interval_max. Reducing the tcp_rexmit_interval_max value to less than half the value of tcp_ip_abort_interval ensures that the parameter tcp_timer_backoff never doubles to a value greater than the tcp_ip_abort_interval.
Note The tcp_rexmit_interval_initial and tcp_rexmit_interval_max parameters can be tuned using ndd, but tcp_timer_backoff is set internally.
If the disconnect is accompanied by errors in the server log, such as Error 1608:
A client process exited abnormally, or a network error was encountered. Unless other errors occurred, continue processing normally.
or Error 1605:
Failed to open virtual socket for new connections
check with your network administrator for possible network problems. Your administrator may have to use a tool such as a sniffer to do this. See the Adaptive Server Enterprise Troubleshooting and Error Messages Guide for information on server errors. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -16
General SQL Server error

Error Number 20018 (SYBESMSG) Severity 5 (EXSERVER) Message Text
General SQL Server error: Check messages from the SQL Server.
Possible Cause This error usually accompanies an error from the server. A server error occurred while processing a SQL command sent by the application. The command could be a direct SQL command sent in a dbcmd call or an indirect SQL command in a dbrpcsend, dbwritetext or dbsetopt call. Action To resolve the problem, take the following actions as appropriate: Check the server error message that accompanies the client error message to try to locate the problem. If you need more information, check the servers error log. If you think the problem might be in a query, try executing it in isql. If the query does not work in isql, x the query rst. If the query works in isql, look at your program for parameters passed at runtime that might cause the problem. Use the following call to see the SQL commands being sent by the application:
dbrecftos("<filename>");
The following example shows how to use dbrecftos:
Page -17
..... DBPROCESS *dproc; LOGINREC *login; char tab_name[33]; ..... dbrecftos("dblib.log"); dbproc = dbopen(login, NULL); ..... printf("Enter table name: "); gets(tab_name); dbfcmd(dbproc,"select * from '%s'", tab_name); ....
In this example, all SQL sent by the application is recorded in a le called dblib.log.0. If the query recorded does not look right, check your code again for logic errors and parameter substitutions. Check the server log for related errors if the problem is not obvious or the occurrence is inconsistent. The dbrecftos call is especially useful if the error occurs on an indirect SQL call such as with dbwritetext. See the DB-Library/C Reference Manual page for dbrecftos for more information. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -18
Results pending
Error Number 20019 (SYBERPND) Severity 7 (EXPROGRAM) Message Text
Attempt to initiate a new SQL Server operation with results pending.
Possible Cause This error occurs when you try to send a new command to the server before all the results of the previous command on the same connection have been completely processed. A connection in DBLibrary is single-threaded and synchronous; it can handle only one request to the server at a time. Although this request may contain multiple commands, a new request cannot be initiated until all the results from the rst request set have been fully processed or cancelled. You are allowed to batch multiple SQL commands as one command request (one dbcmd or dbfcmd call). For example, the following command:
dbcmd(dbproc, "select * from authors select title from titles");
contains two SQL commands, but makes only one SQL operation request to the server. Action To resolve the problem, take the following actions as appropriate: The error often occurs when a DB-library program does not loop correctly on the results returned by the server. The proper way for any DB-library program to handle results is:
Page -19
..... RETCODE result_code; DBPROCESS *dbproc; ..... /* Process each command until there are no more results. */ while ((result_code = dbresults(dbproc)) != NO_MORE_RESULTS) { if (result_code == SUCCEED) { /* If this is a command that returned rows */ if(DBROWS(dbproc)) { /* Do the binds */ ....... while (dbnextrow(dbproc) != NO_MORE_ROWS) { ....... } } else /* handle non-row results appropriately */ } else /* Handle failures appropriately */ } /* end of result processing loop */
Use this programming logic for processing results even when you expect a command to return only one result set. This method is consistent for single or batched commands and can handle one or multiple result sets. It safeguards your applications against changes in tables or stored procedures, and even changes in SQL behavior that may occur in future releases of the server. If you want to send a new request to the server on the same DBPROCESS connection without processing all results from the rst request, you must cancel the results from the rst request. Use dbcancel to cancel results if you sent a batch of SQL commands, dbcanquery if you sent a single command. Calling dbcanquery is equivalent to calling dbnextrow until it returns NO_MORE_ROWS, but dbcanquery is faster because it doesnt bind data. If you want to initiate a new SQL request while still processing results from the rst, and cancelling the current result set is not an
Page -20
option, open a new connection with a new DBPROCESS structure. If you wish to fetch or update rows without using cursors, and cannot open a new connection because of possible lock contention, evaluate the method demonstrated by the following example. For example, the code shown here causes the 20019 error:
..... DBPROCESS *dbproc; RETCODE result_code; DBCHAR col1[100]; ..... /* Issue the query */ dbcmd(dbproc, "select col1 from table1 "); if (dbsqlexec(dbproc) == fail) /* Handle the error */ ..... /* Process results. */ while ((result_code = dbresults(dbproc)) != NO_MORE_RESULTS) { ..... /* bind rows to host variable */ dbbind(dbproc, 1, NTBSTRINGBIND, (DBINT)0, col1); /* While there are rows, display the row, then ** issue the command for update. */ while (dbnextrow(dbproc) != NO_MORE_ROWS) { printf("Row value = %s\n", col1); dbfcmd(dbproc,"update table1 set col1 = new_value"); ..... } ..... }
This code causes the error because it issues a second command on the same DBPROCESS as the select, without rst processing all the results from the select. The following code avoids the error without using cursors. It processes the results, then uses a temporary array to hold the data while you perform the updates:
Page -21
/* ** ** ** */
Allocate a structure to store all the returned values for the select. The size of the array should be the maximum number of rows you expect.
..... struct { char tmp_col1[100]; } objects[20]; ..... /* Issue the query. */ dbcmd(dbproc, "select col1 from table1 "); if (dbsqlexec(dbproc) == fail) /* Handle the error */ ..... /* Process results. */ while ((result_code = dbresults(dbproc)) != NO_MORE_RESULTS) { ..... /* bind rows to host variable */ dbbind(dbproc, 1, NTBSTRINGBIND, (DBINT)0, col1); /* fetch a row into the host variable. Repeat ** until there are no more rows. At the end ** of the loop, all the data will have been ** transferred from the bound host variable to ** another variiable for future processing. */ while (dbnextrow(dbproc) != NO_MORE_ROWS) { /* Now transfer the data to the host array to ** store the row values for future updates ** or any other processing. */ strcpy(objects[i].tmp_col1, col1); i++; } ..... } /* You have fetched all the rows from the select'; now you ** can use the same DBPROCESS to perform the updates. Scan ** the array for the row to update. */ ..... for (i = 0 ; i < DBCOUNT(dbproc) ; i++) {
Page -22
dbfcmd(dbproc, "update table1 set col1 = new_value" where col1 = '%s'", objects[i].tmp_col1"); if (dbsqlexec(dbproc) == fail) /* Handle the error */ ..... /* Process results from the update. */ while ((result_code = dbresults(dbproc)) !=NO_MORE_RESULTS) ..... }
Page -23
Bad token from SQL Server

Error Number 20020 (SYBETOK) Severity 9 (EXCOMM) Message Text
Bad token from SQL Server: Data-stream processing out of sync.
Possible Cause The following are the most common causes of this error: This error usually occurs because the communication between the client and the server becomes corrupted or out of sync. The corruption may be in the database you queried, or a network problem may have caused the data stream to become corrupt. Heavy network trafc could cause the error as well, in which case the error is usually transient. The error may occur when the client and server are at different TDS levels. TDS is Sybase's proprietary protocol used for communication between server and client. If the server and client are at different release levels, the server might send a token at a higher TDS level than the client which the client does not understand. Issuing too many cancels (dbcancel or dbcanquery) can also cause data processing to go out of sync. Action Check for errors in the server log, especially for 605 errors related to corruption in the database. Ask your Sybase database administrator to correct these rst. If there are no errors in the server log related to corruption, check for other errors that relate to the network. Contact your network administrator to check on possible network problems. If you are running an 11.x server, be sure that you are using a compatible level of DB-Library (at least 10.x) and that your application sets the DB-Library version to 10 by making the following call:
Page -24
dbsetversion (DBVERSION_100)
that sets the TDS level to the current level. Keep cancels to a minimum and use dbcanquery rather than dbcancel if possible. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -25
Unknown bind type

Error Number 20023 (SYBEBTYP) Severity 7 (EXPROGRAM) Message Text
Unknown bind type passed to DB-Library function.
Possible Cause This error occurs when you specify an invalid bind type for a variable at bind time. Often, this happens because you used a bind type that was introduced in Release 10.x, but did not set the product version to 10 in the application. DB-Library 10.x and later defaults to 4.x behavior for backward compatibility. If you want to use features from later releases, you need to explicitly set the product version in the application. DB-Library calls that can raise this error are dbbind, dbaltbind,
dbcursorbind and dbsetnull.
Action To resolve the problem, take the following actions as appropriate: Check your code to verify that dbbind, dbaltbind, dbcursorbind, and dbsetnull calls use only valid bind types. Although most bind type errors are found when you build the application, some are found only at runtime. The following types of binds (and datatypes) were introduced in version 10.x: - NUMERICBIND - DECIMALBIND - SENSITIVITYBIND If your program uses any of these bind types, you must set the DB-Library version to 10. To do this, call dbsetversion after dbinit and before making any other calls, as in this example:
Page -26
.... /* Initialize DB-Library */ dbinit(); /* Set the version to 10.x and up behavior */ dbsetversion(DBVERSION_100); ....
If you do not set the DB-Library version to 10, DB-Library uses 4.x behavior, which did not include support for numeric or decimal datatypes. For More Information See the Open Client DB-Library/C Reference Manual sections on
dbbind, dbaltbind, dbcursorbind and dbsetnull for lists of legal bind type
values, as well as their corresponding server and program variable types. [XREF] See also the section in this manual for Error 20060. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -27
Unknown datatype encountered

Error Number 20029 (SYBEUDTY) Severity 7 (EXPROGRAM) Message Text
Unknown datatype encountered.
Possible Cause This error occurs when your application uses numeric or decimal datatypes, and one of the following conditions exists: You are using a pre-10.x version of DB-Library You are using DB-Library 10.x or 11.x, but have not explicitly set the version to 10. The numeric and decimal datatypes were introduced in version 10, but DB-Library defaults to 4.x behavior for backward compatibility. If you need 10.x behavior, you have to set the version explicitly in your programs. The error can occur on calls to dbconvert, dbrpcparam, dbcoltypeinfo, dbwillconvert, bcp_bind and any other call that references types SYBNUMERIC, SYBDECIMAL, SYBBOUNDARY or SYBSENSITIVITY. For example, suppose the application executed the following stored procedure on the server:
create proc test_proc(@param numeric(25,2)) as insert test_table values(@param) return
and the application passed the parameter as:

...... DBNUMERIC num_var; ...... dbrpcparam (dbproc, "@param", (BYTE)0, SYBNUMERIC, -1, -1, (BYTE *)&num_var); ......
Page -28
You would get the error unless you were running DB-Library 10.x with the version set to 10. Action To resolve the problem, be sure your are running DB-Library 10.x. In your application, set the version to 10 as follows to evoke 10.x behavior:
Make this the rst DB-Library call, or the call immediately after dbinit. Adding this call will allow you to use version 10 features. Do this even if you are running DB-Library 10.x or 11.x. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -29
Attempt to bind to a non-existent column

Error Number 20032 (SYBEABNC) Severity 7 (EXPROGRAM) Message Text
Attempt to bind to a non-existent column.
Possible Cause This error usually occurs when a DB-Library program attempts to bind a host variable to a column that does not exist in the select list of the previous dbcmd or dbrpcsend call. For example, suppose you issue the following command, which lists two columns in the select:
select pub_id, city from pubs2.dbo.publishers
You can bind columns 1 and 2, but an attempt to bind column 3 will trigger the error. Action To resolve the problem, take the following actions as appropriate: Check the number of binds issued by the application after a select command. It should match the number of columns in the select list. If the command which triggers the error is a request to execute a stored procedure, check the stored procedure denition to match the number of columns with the number of binds. It is possible that the stored procedure or table denitions have changed within the server. If the number of columns in the select list and bind call matches and the error persists, you may be getting incomplete data. Check with your network administrator to see if network problems could be causing data packets to be lost or broken. Your network administrator may use a tool such as a sniffer to check for problems. If taking these steps does not resolve the problem, contact Sybase Technical Support. You may need to run a Sybase proprietary debugging tool such as capture to diagnose the problem.
Page -30
Page -31
dbbind() with mismatched column and variable types

Error Number 20033 (SYBEABMT) Severity 7 (EXPROGRAM) Message Text
User attempted a dbbind() with mismatched column and variable types.
Possible Cause This error occurs when DB-Library cannot perform the requested type of bind for the specied host variable.This example illustrates the problem:
.... DBCHAR date_var; .... dbcmd(dbproc,"select getdate()"); .. dbsqlexec(dbproc) ... while ((dbresults(dbproc)) != NO_MORE_RESULTS ) { dbbind( dbproc, 1, INTBIND, 0, date_var); .... }
This code causes the error because it tries to perform a bind of type INTBIND on a datetime value. Action To resolve the problem, check the bind type specied in the program against the datatype of the column requested. See the Open Client DB-Library/C Reference Manual page for dbbind for a list of valid bind types and their corresponding host variable and server datatypes. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -32
Attempt to retrieve data from a non-existent row

Error Number 20044 (SYBERDNR) Severity 7 (EXPROGRAM) Message Text
Attempt to retrieve data from a non-existent row.
Possible Cause This error occurs when the server does not return the expected rows because: Your select has a where qualier and no rows in the table meet the qualication. The table contains no rows. The error can be returned by any of the following routines: dbqual dbtsput dbdata dbdatlen dbtxplen dbtxptr dbtxtimestamp The following examples show how you can get the error if you call one of these routines without rst checking to see if your query returned any rows. In the rst example, the program uses browse mode to select and update rows. However, the employee table contains no rows, causing the dbqual routine to fail with the error:
Page -33
..... DBPROCESS *dbproc; char *qualptr; ..... dbcmd(dbproc, "select * from employee for browse"); ... dbsqlexec(dbproc) ...; ... dbresults(dbproc) .... ..... qualptr = dbqual(dbproc, -1, "employee"); .....
Similarly, the next example shows how you can get the error by calling dbdata when the employee table has no rows.
..... DBPROCESS *dbproc; char data[100]; ..... dbcmd(dbproc, "select * from employee "); dbsqlexec(dbproc); dbresults(dbproc); dbconvert ( dbproc, ( dbcoltype(dbproc,1)), dbdata(dbproc,1), (int)dbdatlen(dbproc,1), SYBCHAR, data, -2); printf("Data == %s\n", data); ....
Action To resolve the problem, verify that you call the routines listed in the previous section only if a row is available. Use a sequence of commands similar to this: - Call dbresults in a loop until it returns NO_MORE_RESULTS - Use DBROWS to verify that rows were returned - Call dbnextrow in a loop until it returns NO_MORE_ROWS - Call the routine to process the row See Results pending in this manual for an example of this logical sequence of operations. See also the online samples in the SYBASE/sample/dblibrary directory as a guide to using the routines in the previous section. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -34
DBPROCESS is dead or not enabled

Error Number 20047 (SYBEDDNE) Severity 1 (EXINFO) Message Text
DBPROCESS is dead or not enabled.
Possible Cause This error occurs when a DB-Library connection to the server is no longer available. DB-Library marks a DBPROCESS dead when an error occurs that makes the DBPROCESS unusable in any future DBLibrary call. The most common reasons for this error include: The server experienced a severe error while processing a query sent by the DB-Library program. Severe server errors include deadlocks (Error 1205), corruption (605), and memory problems (803). See the Adaptive Server Enterprise Error Messages Guide for information on server errors. A server timeout error occurred and the error handler returned an INT_CANCEL. You have exceeded the maximum number of user connections for the server. While the server was returning data to the client, network problems or an I/O error caused it to drop the connection. An operating system error could also cause the server to drop the connection. See the section Unexpected EOF from SQL Server for details on a known operating system bug on Solaris that can cause this error. You have connected to a non-Sybase server that does not understand the Sybase proprietary protocol, TDS. Memory allocation errors can also cause the error, for example, very large chunks of text/image data. Action To resolve the problem, take the following actions as appropriate:
Page -35
Check the server error log for error messages recorded at the time the 20047 error occurred. Refer to the Adaptive Server Enterprise Troubleshooting and Error Messages Guide more information on these errors. If the error occurs after a server timeout error, see the Open Client DB-Library/C Reference Manual page for dberrhandle for details on handling timeout errors without killing the DBPROCESS. Check with your network administrator to see if you are experiencing network problems. If you are asking the server to open more connections than it is congured for, try increasing the number of user connections parameter on the server. Contact your database administrator or see the section on setting conguration variables in the System Administration Guide for instructions on resetting this parameter. If the problem happens randomly and no errors appear in the server error log, or if the error started after an operating system change, check both the Sybase website and information published by your operating system vendor for related bugs. Verify that your DB-Library application is connecting to a Sybase server that understands TDS. If you are getting errors while dealing with large chunks of text or image data, you could be having memory allocation failures. Try breaking the data into smaller chunks. See the sections on dbwritetext and dbmoretext in the Open Client DB-Library/C Reference Manual. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -36
Syntax error in source eld

Error Number 20050 (SYBECSYN) Severity 4 (EXCONVERSION) Message Text
Attempt to convert data stopped by syntax error in source field.
Possible Cause The main reason for this error is a failure in an implicit or explicit conversion by dbconvert. This can occur when: You make a direct call to dbconvert to perform a conversion that is not supported or has resulted in a conversion error. DB-Library makes an implicit call to dbconvert as in a bind call, which results in a conversion error. In a bind call, the error could occur if either the data or the bind specications were incorrect. For example, suppose you tried using bcp_bind to copy the following comma-delimited datale:
hello,world
into a table dened as:

create table test(col1 char(5), col2 int)
The second column, col2, is dened as integer, but the datale contains character data in the corresponding column, resulting in the error. Action To resolve the problem, take the following actions as appropriate: If you make an explicit call to dbconvert, check the type of conversion you specied and verify that the conversion is allowed. If it is a valid conversion, check the source data and see if it is valid. If the error occurs on bcp routines, check the data in the datale or in your host variables. If you recently began experiencing the error with an application, it may be that table denitions in the
Page -37
server have changed. Map your data to the server column datatype and make sure that they match. Then, check your datale against the bind type specied in your application. If your datale or host variable data is in ASCII format, you must specify the bind type as SYBCHAR for all columns, regardless of the corresponding server column type. All necessary conversions are done implicitly. Your data is in native or binary format if you: - Run bcp with the -n option - Use bcp_exec to copy the data - Bind the data with types of INTBIND, NUMERICBIND and so on If this is the case, you must specify the same bind type on the copy in operation. To help locate the error if it occurs with bcp, specify an error le in your bcp_init call. DB-Library writes the row and column where the error occurred to the error le. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -38
Unknown network type found in interface le

Error Number 20055 (SYBEUNT) Severity 2 (EXUSER) Message Text
Unknown network type found in interface file.
Possible Cause Possible causes of the error include the following: This error is usually raised by the network layer during a dbopen call when the server entry in the clients interfaces le is in the wrong format for the network protocol. For example, a TLI-based network protocol such as Sun Solaris looks for a server entry in tli format, whereas a socket-based protocol such as HP-UX looks for a corresponding socket-based tcp/ip format. A TLI-based entry looks like this:
SYBASE query tli tcp /dev/tcp \x000213e09d852c880000000000000000 master tli tcp /dev/tcp \x000213e09d852c880000000000000000
A socket-based tcp/ip entry for the same server looks like this:
SYBASE query tcp ether prod1 5088 master tcp ether prod1 5088
If the server entry in the clients interfaces le is in a format different than the one DB-Library expects for your operating system, you will get an error. Entries in the interfaces le are automatically formatted correctly for the network protocol when you use a Sybase tool such as sybsetup to install your product or add a server to your conguration. Formatting errors can result when you hand-edit the interfaces le, copy an interfaces le from one machine to another, or use an interfaces le on an NFS-mounted le system from a different platform.
Page -39
Note The format of the interfaces le entry must correspond to the clients network protocol, not the servers.
The error can also occur if the entry has a formatting mistake. Sybase products, including DB-Library, require an interface entry to be in a specic format. This is the format of a non-tli tcp/ip entry:
# put comments here<newline> SERVERNAME<tab>retry_attemps<tab>delay_interval<newline> <tab>service_type protocol network machine port<newline>
If the tabs are missing or you have characters other than a single space before the keywords query or master, you can get the error. Action Always use a Sybase-supplied tool to enter server information in the interfaces le. For example, use sybinit for DB-Library 4.x and 10.x, and dsedit for 11.x and above releases. This ensures that the interfaces le entry is in the correct format for the platform and product version. See the server installation or conguration manual for more information on interfaces le formats. See also the Client-Library error No driver of the requested protocol class in Chapter 3, Client Library Error Messages. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -40
Too much TEXT data via the bcp_moretext() call

Error Number 20095 (SYBEBTMT) Severity 7 (EXPROGRAM) Message Text
Attempt to send too much TEXT data via the bcp_moretext() call.
Possible Cause The bcp_moretext call is used in conjunction with bcp_bind and bcp_sendrow to send a large SYBTEXT or SYBIMAGE value to the server in a number of smaller chunks. The general syntax of the
bcp_moretext call is: bcp_moretext(dbproc, size, text)
The error occurs if the sum of the sizes specied in a series of bcp_moretext calls is greater than the size specied in the bcp_bind or bcp_collen call for the text or image column. For example, if you dened a table as:
create table test (col1 int, col2 text)
and wished to send the data for the second column in chunks, we might say:
..... text_col1[5000], text_col2[5000]; ..... strcpy(text_col1, "The sun was up and the tent was starting to get hot. Nick crawled out under "); strcpy(text_col2, "the mosquito netting stretched across the mouth of the tent, to look at the morning. "); ..... if (bcp_bind (dbproc, (BYTE *)NULL, 0, (DBINT) (strlen(text_col1) + strlen(text_col2)) (BYTE *)NULL, 0, SYBTEXT, 2) == FAIL ) ..... char
Page -41
/* Now send this row, with the text value broken into chunks. */ if (bcp_sendrow(dbproc) == FAIL) ..... if (bcp_moretext(dbproc, (DBINT)sizeof(text_col1), text_col1) == FAIL) ..... if (bcp_moretext(dbproc, (DBINT)sizeof(text_col2), text_col2) == FAIL) .....
This code produces the error because the function sizeof used as a parameter for bcp_moretext indicates that 5000 bytes are being sent for each bcp_moretext call. The bind call, using the strlen function, indicated that a total of 161 bytes were to be sent. Rewriting the code as follows avoids the error:
if (bcp_moretext(dbproc, (DBINT)strlen(text_col1), text_col1) == FAIL) ..... if (bcp_moretext(dbproc, (DBINT)strlen(text_col2), text_col2) == FAIL) ..... Note The sizeof function refers to the maximum size of the variable that it acts upon. Confusing sizeof with strlen the actual length of the character data contained in the variable is a common reason for this error.
Action To resolve the problem, verify that the sum of the sizes specied in all of the bcp_moretext calls for the text or image column is equal to the size of the column specied in the bcp_bind call (or bcp_collen if used in place of bcp_bind). See the page for bcp_moretext in the Open Client DB-Library/C Reference Manual for an example, as well as notes on handling multiple text and image columns in the same table. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -42
dbreadtext() may only be used to receive the results...

Error Number 20118 (SYBERTSC) Severity 7 (EXPROGRAM) Message Text
dbreadtext() may only be used to receive the results of a query which contains a single result column.
Possible Cause The dbreadtext is used to process the results of a SQL query that returns only one column, which must be of text or image datatype. The error occurs if a query returns more than one column of any type. For example, if you had a table dened as:
create table test(id int, text_col text )
and your program was coded as follows:

.... #define BUFSIZE 100 DBPROCESS *dbproc; RETCODE ret; DBINT bytes = 0; char buf[1000]; .... dbcmd(dbproc, "select * from test"); dbsqlexec(dbproc); /* Process the results: */ while((ret = dbresults(dbproc)) != NO_MORE_RESULTS)
Page -43
{ if( ret == FAIL ) { /* dbresults() failed */ } while( (bytes = dbreadtext(dbproc, (void *)buf, BUFSIZE)) != NO_MORE_ROWS ) .... } ....
you would get the above error. The correct query would be:
dbcmd(dbproc, "select text_col from test");
If your query selects a single column of a datatype other than text or image, you get neither results nor an error message. Action Check the query in your application. Be sure that it selects only one column of type text or image. State the column name in the query rather than issuing a query in the form of select * from table. This ensures that you get results only from the desired column, even if the table denition changes. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -44
Zero length TEXT or IMAGE to dataserver via dbwritetext()

Error Number 20169 (SYBEZTXT) Severity 1 (EXINFO) Message Text
Attempt to send zero length TEXT or IMAGE to dataserver via dbwritetext().
Possible Cause This error occurs if you set the value of the size parameter in the
dbwritetext call to 0 and the value of the text parameter to NULL. The syntax of the dbwritetext call is: dbwritetext(dbproc, objname, textptr, textptrlen, timestamp, log, size, text
where size is the size of the data to send to the server and text is a pointer to the buffer containing the text or image data. You can enter NULL as the value of text if you intend to send the data in chunks using dbmoretext calls. The following example illustrates one way the error can occur:
.... DBPROCESS *u_dbproc; DBBINARY *txptr; /* text pointer */ DBBINARY *ts_ptr; /* time stamp */ char *buf; int size = 0; .... dbwritetext (u_dbproc, "au_pix.pic", txptr, DBTXPLEN, ts_ptr, TRUE, size, (BYTE *)buf); ....
This code raises the error because the size parameter is set to 0 and buf, the text value for update, is NULL.
Page -45
Note If the size parameter is set to 0, but the value of the text parameter is not NULL, the dbwritetext call does not fail, but the update will not take place.
The error could also occur if you set the value of the size parameter to a value greater than the variable can hold. This causes numerical overow, and the value in the variable then becomes a negative number. See Called dbmoretext with a bad size parameter for an example. Action Set the size parameter to a value greater than 0, specically, the size of the text or image data you want to send. If the size parameter is greater than 0 and the text or image value is NULL, the application must call dbmoretext to write the data in chunks. See the page on dbwritetext in the Open Client DB-Library/C Reference Manual for an example that illustrates the last combination. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -46
DBPROCESS is being used for another transaction

Error Number 20180 (SYBETRAN) Severity 1 (EXINFO) Message Text
DBPROCESS is being used for another transaction.
Possible Cause This error occurs when you initiate an RPC event on a DBPROCESS structure and then make a second request of the same kind before the rst request has been completed. The term transaction in this case applies to a command such as an RPC operation, a registered procedure operation, or a passthrough operation using Open Server with DB-Library. It does not refer to a transaction as dened by the begin tran and commit or rollback tran SQL commands. The follow example illustrates the problem. Two dbrpcinit commands occur in succession on the same DBPROCESS structure; rcpA has not been completed before rpcB is sent:
dbrpcinit(dbproc,"rpcA",...); dbrpcinit(dbproc,"rpcB",...);
Action To resolve the problem, take the following actions as appropriate: If, after initiating a transaction, you do not wish to continue with it, and want to initiate a different transaction, cancel the rst transaction with dbcancel. If you wish to continue processing the current transaction, you must complete the logical sequence of commands required to send it to the server and process the results. For RPC commands, the typical sequence is:
Page -47
..... dbrpcinit dbrpcparam dbsqlsend dbsqlok dbresults dbnumrets dbretstatus
/* if parameters exist */
/* process in a loop until no more results */ /* check for any return parameters */ /* get the return status */
See the Open Client DB-Library/C Reference Manual page for the DBLibrary call you are using for the correct sequence of commands. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -48
Called dbmoretext with a bad size parameter

Error Number 20188 (SYBETEXS) Severity 1 (EXINFO) Message Text
Called dbmoretext with a bad size parameter.
Possible Cause The error occurs if you set the size parameter in a dbwritetext or dbmoretext call to a value less than zero. The dbwritetext call is used to read large text or image data in smaller chunks from the server. The general syntax of the dbwritetext call is:
dbwritetext(dbproc, buffer, bufsize)
where buffer is a pointer to a caller-allocated buffer for the chunk of text or image data and bufsize is the size in bytes of the buffer. The dbmoretext call is used in conjunction with the dbwritetext call to send large image or text data to the server in smaller chunks. The general syntax of the dbmoretext call is:
dbmoretext(dbproc, size, text)
where size is the size in bytes of the chunk of text or image data being sent to the server and text is a pointer to the text or image portion to be written.
Note The error message text is the same whether the error is raised by dbwritetext or dbmoretext.
The error could occur if you set the value of the size parameter to a value greater than the variable can hold. This causes numerical overow, and the value in the variable then becomes a negative number. In the following example, the variable size_val, intended to hold the value of the size parameter, was created as a short datatype. However, the buffer created to hold the image data is 100,000 bytes, which is
Page -49
beyond the range of values for a short datatype. The following code would produce the error:
... short size_val; DBBINARY image_val[100000]; .... size_val = sizeof(image_val);
The code tries to set size_val to 100,000, causing it to overow and be assigned a negative value. No error is raised by C, but when you use this parameter in a dbmoretext call, you get this error. Action If possible, check the value of the size parameter before calling dbwritetext or dbmoretext. To resolve the problem, set the size parameter in the dbwritetext or dbmoretext call to a value greater than zero. See the sections on dbwritetext and dbmoretext in the Open Client DBLibrary/C Reference Manual. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -50
Packet size of %1! not supported

Error Number 20201 (SYBEBADPK) Severity 1 (EXINFO) Message Text
Packet size of %1! not supported -- size of %2! used instead.
Possible Cause This error occurs when the client requests a valid packet size (between the default and maximum network packet sizes), but the server is unable to use the size at the time. DB-Library and the server negotiate the packet size at login time. Memory for default packet sizes is allocated from the server memory pool. Memory for packet sizes larger than the default is allocated from the additional network memory pool. If the additional memory pool does not have enough memory to handle the larger packet size request from DB-Library, the server will set the packet size to the value it can support from the additional memory pool. If no more additional memory is left, the server sets the packet size at the default value. If DB-Library is unable to negotiate the requested packet size, it raises the error. Action To resolve the problem, contact your Sybase system administrator and request an increase in the additional network memory parameter for the server. Use the following formula to calculate additional memory needed: 1. Estimate the number of simultaneous users requesting the large packet size and multiply this number by the packet size. 2. Multiply the previous result by three, because each connection gets three buffers for sending or receiving data on the network. 3. Add 2% overhead, rounded up to the nearest multiple of 512. For example, if the default packet size is 512, the maximum network packet size is 8192, and the number of clients that could
Page -51
simultaneously request this packet size is 2, then additional network memory needed could be calculated as follows:
2 * 8192 = 16384 49152 16384 * 3 =
(1.02 * 49152) = 50135.04 Additional netmem = 50176
See the System Administration Guide for more details on tuning the additional network memory parameter. Versions in Which This Error Is Raised DB-Library/C 4.x and later
Page -52
Function can be called only once

Error Number 20207 (SYBEONCE) Severity 7 (EXPROGRAM) Message Text
Function can be called only once.
Possible Cause If you use the dbsetversion call to change the behavior of a DB-Library 10.x or 11.x program, you must make that call rst or right after dbinit. Otherwise, DB-Library implicitly sets the version to 4.6 when it requests a server login. If you make the dbsetversion call later in the program, DB-Library thinks you are making the call twice, and raises the error. All current versions of DB-Library default to DB-Library 4.6 behavior for backward compatibility. This means that new features in 10.x and later releases (such as numeric and decimal datatypes or client cursors) are not be available to the program. If you want to use features available in 10.x or later, you have to set the program version to 10 by making a call to dbsetversion. Action Unless you are connecting to a 4.9 server, you should set the version to the 10.x level to take advantage of the additional features. Make the following call to set the version to 10:
This should be the rst call in the program or the rst call after dbinit. The only valid values for dbsetversion are: DBVERSION_100 DBVERSION_46 Specifying any other level causes the following error:
Error #: 20206 (SYBEIVERS) Message: Illegal version level specified.
Page -53
Page -54
RPC parameters cannot be of type Text/Image

Error Number 20209 (SYBERPTXTIM) Severity 7 (EXPROGRAM) Message Text
RPC parameters cannot be of type Text/Image.
Possible Cause Your application attempted to pass parameters of type text or image to a stored procedure. These datatypes are not supported by the server for stored procedures, so you cannot dene a stored procedure to contain them, nor can you pass them as parameters from a client application. Action To resolve the problem, check your code to see if your DB-Library application passes parameters of host variable type SYBTEXT or SYBIMAGE in a dbrpcparam call, then check the stored procedure denition in the server. Change the host parameter types to ones which correspond to the stored procedures datatypes. Use one of the following methods to write the data to the server: Use the dbwritetext call to write large text or image values. See the online sample example9.c in the $SYBASE/sample/dblibrary directory. If the text or image data is small for example, a few thousand bytes you can copy the entire value into a buffer and send it to the server in a dbcmd call. For example:
Page -55
..... DBPROCESS *dbproc; char cmd_buff[500]; DBBINARY img_col; ..... img_col = 0x123456789; strcpy(cmd_buff,"insert big_table(img_col)values('%x')", img_col); dbcmd(dbproc, cmd_buff); dbsqlexec(dbproc); while (dbresults(dbproc) != NO_MORE_RESULTS ) .....
Page -56
A
ISQL
Commands to Find Sybase Versions
A.
The following are commands that you can use to nd out the version of Sybase utilities and libraries. Issue these commands issued from the shell prompt.
UNIX
$SYBASE/bin/isql -v
Windows, DOS
%SYBASE%\bin\isql -v
VMS
isql /version
BCP
UNIX
$SYBASE/bin/bcp -v
Windows, DOS
%SYBASE%\bin\bcp -v
VMS
bcp/version
Precompilers
UNIX
$SYBASE/bin/cpre
Or:
Page -1
$SYBASE/bin/cobpre (for ESQL/COBOL )
Windows, DOS
%SYBASE%\bin\cpre
Or:
%SYBASE%\bin\cobpre ( for ESQL/COBOL ).
VMS
cpre /version
Or:
cobpre /version ( if using esql/cobol ).
ESQL Library Version

UNIX
strings $SYBASE/lib/libct.a | grep -i Sybase
For COBOL:
strings $SYBASE/lib/libcobct.a | grep -i Sybase
Windows, DOS
find /I "intel" %SYBASE%\dll\libct.dll
VMS
search libct.olb /form=nonull Sybase
For COBOL:
search libcobct.olb /form=nonull Sybase
Open Client/Server libraries:

The general form of the command to determine the version of an Open Client/Server library is as follows: UNIX
strings $SYBASE/lib/<library_name> | grep -i Sybase
Page -2
Windows, DOS
find /I "intel" %SYBASE%\dll\<library_name>
VMS
search <library_name> /form=nonull Sybase
In general, these commands can be issued on any of the library les under the lib or dll directory (depending on your platform) in the Sybase installation directory. The following table gives examples of les you can use to substitute for library_name for different products:
To get the version of:

DB-Library CT-Library Open Server-Library
Issue the command on:

libsybdb.x libct.x libsrv.x
The extension denoted by x in the name of the library can vary according to the platform and to whether you link dynamically or statically. For example, to get the Client-Library version for the platforms in the table, issue the following commands: UNIX
strings $SYBASE/lib/libct.a | grep -i Sybase
Windows, DOS
find /I "intel" %SYBASE%\dll\libct.dll
On VMS
search libct.olb /form=nonull Sybase
Page -3
Page -4
Open Client/Server 10.0.x and 11.x Runtime Environment B.

The following is a list of les required in your Sybase environment to run Open Client/Server 10.0.x and 11.x applications.
Files Required in $SYBASE

interfaces
Files Required in $SYBASE/lib

If Application Has Been Complied Statically
Version 10.0.x None Version 11.x only You need the following Net Library les: TLI- based platforms: libtli.so Socket-based platforms: libinsck.so.a or .sl If using threaded libraries on 11.x You need the following Net Library les: TLI- based platforms: libtl_r.so Socket-based platforms: libinsck_r.so.a or libinsck_r.sl
If Application Has Been Compiled Dynamically

If the application has been compiled dynamically, you need the following shared libraries (.sl on some platforms): libcomn.so libcs.so libct.so
Page -1
libintl.so libtcl.so libtli.so, libinsck.so.a or libinscl.sl Version 11.x only If using threaded libraries, you need the 'libxxxx_r.xx' versions of the libraries listed in the previous section.
Files Required Under $SYBASE/include

None
Files Required Under $SYBASE/cong

Version 11.x only libtcl.cfg objectid.dat mnemonic.dat, if the conversion conguration le, charset.cfg, for a destination character set species a mode of Mnemonic.
Note The $SYBASE/cong directory does not exist in 10.0.x versions of Open Client/Server.
Files Required Under $SYBASE/locales

Version 10.0.x locales.dat <language_name>/<charset> (for example, us_english/iso_1) cobct.loc (ESQL/COBOL only) common.loc comnlib.loc cslib.loc
Page -2
ctlib.loc dcllib.loc libinsck.loc (for socket platforms) libtli.loc scllib.loc tcllib.loc Version 11.x locales.dat message/<language_name> (for example, us_english) cobct.loc (for ESQL/COBOL only) common.loc comnlib.loc cslib.loc ctlib.loc dcllib.loc libinsck.loc (for socket platforms) libtli.loc scllib.loc tcllib.loc (for TLI platforms) (for TLI platforms)
Files Required Under $SYBASE/charsets

Version 10.0.x <charset_name> (for example, iso_1) binary.srt charset.loc iso_1.cfg Version 11.x The directory and les listed in the previous section, plus: utf8.ctb
Page -3
utf8 charset.loc cp437.ctb cp850.ctb deckanji.ctb eucjis.ctb iso_1.ctb mac.ctb roman8.ctb sjis.ctb utf8.cfg For a complete list of les shipped with your Open Client/Server product, please refer to the Open Client/Server Supplement for your platform.
Page -4
How to Interpret Client-Library Error SQLCODEs
C.
SQLCODEs are used to perform inline error handling. For a complete discussion of using SQLCODEs, see the Open Client ClientLibrary Reference Manual. This appendix describes the component parts of the SQLCODE and explains how to interpret them.
The Elements of a SQLCODE

An error number in Client-Library is a negative number larger than -16777216 (Client-Library error message numbers are inverted before being placed into the SQLCODE structure, so that the SQLCODE is always negative). The error number is made up of four elds: L = Layer (the Client-Library layer that generated the message) O = Origin (internal or external origin of the error) S = Severity (type of message or failure) N = Number (the layer-specic error number) The following section explains how to nd the number corresponding to each eld.
Breaking Down the SQLCODE to its Components

The nd the value of each SQLCODE eld, perform these calculations: 1. Transform the absolute value of the number into a hexadecimal number 2. Divide the hexadecimal into four bytes 3. Convert each byte back to decimal. 4. Map the four decimal numbers to L, O, S, and N (from left to right). If you are working in C, you can perform the conversions with the Sybase-supplied macros CS_LAYER(), CS_ORIGIN()(), CS_SEVERITY() and CS_NUMBER(). Run these against the absolute value of the SQLCODE. Each macro returns a value between 0 and 255. See the Reference Manual for more information about the macros.
Page -1
Meanings of the Four Parts

The meaning of each component of the SQLCODE is explained below. Whenever SQLCODE indicates an error, there is also an appropriate error message, a concatenation of substrings listed here, available in SQLERRMC (COBOL) or in sqlca.sqlerrm.sqlerrmc (C) The message that you construct by splitting up the SQLCODE into its components and looking up their text strings in the lists below, should always be the same as the error message in SQLERRMC or sqlca.sqlerrm.sqlerrmc.
Layer
The meaning of Layer is as follows: 1 = user api layer 2 = cslib user api layer 3 = generic protocol layer 4 = protocol specic layer 5 = network packet layer
Origin
The meaning of Origin depends on the Layer, as follows: If Layer = 1,3,4 or 5 the meaning of Origin is: 1 = external error 2 = internal Client Library error 3 = internal net library error 4 = internal common library error 5 = internal intl library error 6 = internal async manager error 7 = internal memory management error If Layer = 2, the meaning of Origin is: 1 = external error 2 = internal CS-Library error
Page -2
4 = common library error 5 = intl library error
Severity
The meaning of Severity is as follows: 0 = CS_SV_INFORM (No error has occurred. The message is informational.) 1 = CS_SV_API_FAIL (A Client-Library routine generated an error. Typically caused by a bad parameter or calling sequence.) 2 = CS_SV_RETRY_FAIL (An operation has failed, but the operation can be retried. E.g. a network read that times out.) 3 = CS_SV_RESOURCE_FAIL (A resource error has occurred. Typically caused by a malloc failure or lack of le descriptors.) 4 = CS_SV_CONFIG_FAIL (A SYBASE conguration error has been detected. E.g. missing interfaces- or localization-les, unknown server) 5 = CS_SV_COMM_FAIL (An unrecoverable error in the server communication channel has occurred. Server connection is not salvageable.) 6 = CS_SV_INTERNAL_FAIL (An internal ClientLibrary error has occurred.) 7 = CS_SV_FATAL (A serious error has occurred. All server connections are unusable.) See the table on Client-Library message severities in the Open Client Client-Library Reference Manual for more information
Number
The meaning of Number depends on the Layer, as follows: If Layer = 1 (user api layer), the meaning of Number is: 0 = State validation succeeded. 1 = The information being retrieved will not t in a buffer of %1! bytes. 2 = Memory allocation failure. 3 = The parameter %1! cannot be NULL. 4 = When %1! is NULL the %2! parameter must be 0. 5 = An illegal value of %1! given for parameter %2!. Open Client Error Messages Guide Page -3
6 = The maximum number of connections have already been opened. 7 = The server does not support the KEEP_CON capability. 8 = The %1! parameter must be NULL. 9 = The %1! parameter must be set to CS_UNUSED. 10 = Boolean values must be set to either CS_TRUE or CS_FALSE. 11 = A CS_SIGNAL_CB cannot be installed because the platform does not support interrupt driven network I/O. 12 = A CS_COMPLETION_CB cannot be installed because the platform does not provide the interrupt or polling capabilities needed. 13 = This property cannot be set after a connection to a server has been established. 14 = This property/capability cannot be set. 15 = It is necessary to be connected to a server in order to get this property/capability. 16 = This routine cannot be called while results are pending for a command that has been sent to the server. 17 = The command structure already supports a declared cursor. 18 = A cursor must be declared before this command type can be initialized. 19 = This routine may be called only after a CS_SEND_DATA_CMD command has been initialized. 20 = A command must be initialized before this routine can be called. 21 = This routine cannot be used while a cursor is declared on the command structure. 22 = A cursor has already been declared on this command structure. 23 = The command cannot be initialized after the cursor has been opened. 24 = The cursor on this command structure has already been opened. 25 = Cursor updates and cursor deletes are not allowed after ct_fetch() returns CS_END_DATA.
Page -4
26 = A command has already been initialized on this command structure. 27 = The initialized command cannot have parameters. 28 = A command has already been initialized. 29 = This type of command cannot be batched with the command already initialized on the command structure. 30 = A row must be fetched before this routine may be used. 31 = A cursor rows command cannot be initialized after a cursor open command has been initialized. 32 = The connections capabilities do not support this type of request. 33 = This routine cannot be called after ct_results() returns a result type of CS_CURSOR_RESULT. 34 = This routine cannot be called after ct_results() returns a result type of CS_CMD_DONE. 35 = This routine cannot be called after ct_results() returns a result type of CS_COMPUTE_RESULT. 36 = This routine cannot be called after ct_results() returns a result type of CS_COMPFMT_RESULT. 37 = This routine cannot be called after ct_results() returns a result type of CS_MSG_RESULT. 38 = This routine cannot be called after ct_results() returns a result type of CS_PARAM_RESULT. 39 = This routine cannot be called after ct_results() returns a result type of CS_ROWFMT_RESULT. 40 = This routine cannot be called after ct_results() returns a result type of CS_CMD_FAIL. 41 = This routine cannot be called after ct_results() returns a result type of CS_CMD_SUCCEED. 42 = This routine cannot be called after ct_results() returns a result type of CS_ROW_RESULT. 43 = This routine cannot be called after ct_results() returns a result type of CS_STATUS_RESULT. 44 = This routine cannot be called since an asynchronous operation is currently pending. 45 = There is an internal error in the user api layer.
Page -5
46 = An illegal value of %1! was placed in the %2! eld of the CS_DATAFMT structure. 47 = When dening parameters, names must be supplied for either all of the parameters or none of the parameters. 48 = The server does not support parameters of type %1!. 49 = This routine cannot be called because another command structure has results pending. 50 = The connection has been marked dead. 51 = Exactly one of %1! and %2! must be non-NULL. 52 = In-line error handling must be initialized with the CS_INIT operation before any other ct_diag() action may be taken. 53 = There was not enough memory available to save messages. All previously stored messages have been cleared. 54 = In-line error handling has already been initialized for this connection structure. 55 = WARNING: Existing error and message handlers have been removed. 56 = The message limit cannot be set to a value less than the number of Client-Library or server messages which are currently saved. 57 = A result of type %1! cannot be bound to a program variable of type %2!. 58 = The format eld of the CS_DATAFMT structure must be CS_FMT_UNUSED if the datatype eld is %1!. 59 = If the buffer parameter is NULL then the %1! parameter must also be NULL. 60 = There is a usage error. This routine has been called at an illegal time. 61 = Item of %1! is not greater than the largest item bound. 62 = Item %1! has already been read. 63 = Read from the server has timed out. 64 = The option to specify debug les is not yet supported. All debug information will be sent to stdout. 65 = The requested type of trace information is not yet supported. 66 = A context structure must be supplied when setting/clearing this type of debug information.
Page -6
67 = A connection structure must be supplied when setting/clearing this type of debug information. 68 = Descriptor not found. 69 = A descriptor of name %1! already exists on the connection 70 = The descriptor count of %1! is not possible because it exceeds the maximum count of %2!. 72 = The descriptor %1! has already been associated with a command structure. 73 = The %1! eld of the CS_DATAFMT structure must be set to CS_UNUSED. 74 = When %1! is NULL the %2! eld of the CS_DATAFMT structure must be set to 0. 75 = Inconsistent parameter settings were found for the dynamic descriptor when it was used as input parameters to a command. All descriptor values must be set. 76 = Inconsistent parameter names were found for the dynamic descriptor when it was used as input parameters to a command. A parameter name must be supplied for all of the items or none of the items. 77 = A dynamic de scriptor is being used for input parameters; therefore ct_param() cannot be called. 78 = There are no rows affected. 79 = The bind of result set item %1! resulted in an overow. 80 = The bind of result set item %1! resulted in an underow. 81 = The bind of result set item %1! failed because an illegal precision value was specied. 82 = The bind of result set item %1! failed because an illegal scale value was specied. 83 = The bind of result set item %1! failed due to a syntax error in the source data. 84 = The bind of result set item %1! failed due to an illegal value in the format eld of a CS_DATAFMT structure. 85 = The bind of result set item %1! failed because the source eld value was not within the domain of legal values. 86 = The bind of result set item %1! failed because of an attempt to divide by zero.
Page -7
87 = The bind of result set item %1! failed because Client-Library was unable to get a resource. 88 = The bind of result set item %1! failed. The cause of failure is unknown. 89 = The data for column %1! is NULL but no indicator was available. 90 = The data for column %1! was truncated but no indicator was available. 91 = The bind was missing for column %1!. 92 = A CS_IODESC structure must be set with ct_data_info() before ct_send_data() can be called. 93 = %1! bytes exceeds the amount of bytes specied for this send data operation. Only %2! more bytes can be sent. 94 = The number of bytes specied for this send data operation have not been sent. %1! more bytes need to be sent. 95 = The value %1! was truncated. 96 = No browse information exists. 97 = A CS_IODESC can only be retrieved for text or image columns. Column %1! is not a text or image column. 98 = A CS_IODESC cannot be retrieved for a column that has not been read. Column %1! has not been read. 99 = Capabilities cannot be set after a connection has been established. 100 = Request capabilities cannot be set. 101 = There was a failure initializing the Client-Libray error cache. 102 = This option is not supported by server. 103 = This routine can be called only if the CS_HIDDEN_KEYS property has been set to CS_TRUE. 104 = This message should not be seen. 105 = There was an unexpected failure while retrieving key data. 106 = Column %1! is not a key column. 107 = Column %1! is not nullable. The key data for a column can be set to NULL only if the column accepts NULL values. 108 = The key data supplied for column %1! exceeds the maximum length dened for the column.
Page -8
109 = There was an unexpected failure while setting key data. 110 = A valid count does not exist for the descriptor. 111 = This message should not be seen. 112 = %1! rows affected. 113 = The command structure given to this routine contains notication data or extended error data. This routine does not accept such a command structure. 114 = Extended error data does not exist for message %1!. 115 = A remote password cannot be set when a connection to a server exists. 116 = The server name/password combination supplied exceeds the 255 byte limit enforced by Client-Library. 117 = The CS_DISABLE_POLL property must be set to CS_FALSE when this routine is called. 118 = Unable to open le %1!. 119 = The data must be NULL when dening CS_INPUTVALUE parameters for a ct_cursor(CS_CURSOR_DECLARE) command. 120 = The buffer must be NULL when the current result set consists of format information only. 121 = There is no data associated with descriptor item %1!. 122 = Results are currently being fetched into this descriptor. A descriptor count of %1! is less than the result set size of %2!. 123 = A descriptor has already been specied for the current command. 124 = ct_param() has already been used to dene parameters for the command. 125 = A descriptor of size %1! is not large enough for a result set of size %2!. 126 = Another command structure is using the descriptor. 127 = This routine cannot be called if ct_bind() has already been called for the result set. 128 = The datatype eld of a CS_IODESC must be set to either CS_TEXT_TYPE or CS_IMAGE_TYPE. 129 = An invalid locale was supplied in the %1! structure.
Page -9
130 = An invalid precision or scale in the CS_NUMERIC or CS_DECIMAL value was supplied. 131 = A memory pool cannot be set or cleared if open connections exist on the context structure. 132 = The bind of result set item %1! resulted in truncation. 133 = No rows are affected. More result sets will follow. 134 = The specied id already exists on this connection. 135 = The specied id does not exist on this connection. 136 = A string of length 0 is not allowed for parameter %1!. 137 = A bind count of %1! is not consistent with the count supplied for existing binds. The current bind count is %2!. 138 = A data length of %1! exceeds the maximum length allowed for %2! data. 139 = Setting the precision or scale to CS_SRC_VALUE is allowed only if the corresponding result set column is of type numeric or decimal. 140 = Scale cannot be set greater than precision. 141 = %1! must be 0 or CS_UNUSED when %2! is NULL. 142 = This property can be used only in the appropriate ClientLibrary callback. This property cannot be used in main-line code. 143 = The maximum number of connections cannot be set to a value less than the number of currently existing connections. 144 = This property can be used only if a cursor exists on the command structure. 145 = This property cannot be set when the command structure has results pending or has an open cursor. 146 = The CS_LOCALE structure supplied is not valid. 147 = This routine can be used only with the debug version of Client-Library. 148 = The Client-Library async manager was not able to continue. This connection has been marked dead. 149 = The current rows key has been partially set with ct_keydata(). Every key column must be set with ct_keydata() before this operation can continue. 150 = This routine cannot be called because the context structure is in an undened state. This is probably due to a ct_exit() failure.
Page -10
151 = A connection to the server must exist on the connection structure before this routine can be called. 152 = A command structure must be supplied for a CS_CANCEL_CURRENT operation. 153 = This routine cannot be called when a connection to a server exists on the CS_CONNECTION structure. 154 = This routine cannot be called because the connection structure is in an undened state. 155 = This routine cannot be called when the command structure is idle. 156 = This routine cannot be called when a command has been initialized but not sent. 157 = This routine cannot be called until ct_results() has been called for the command that was sent to the server. 158 = This routine can be called only if fetchable results are available to be read. 159 = This routine can be called only if the command structure is idle. 160 = This routine can be called only if the cursor rows are available to be read. 161 = This routine can be called only if regular row results are available. 162 = A receive passthru operation is not legal while the connection is in the middle of processing results in the standard manner. 163 = This routine cannot be called until all fetchable results have been completely processed. 164 = This routine can be called only if compute results are available. 165 = This routine cannot be called when a nested cursor command is initialized. 166 = This routine cannot be called while the results of a nested cursor command are not completely processed. 167 = This routine cannot be called because the command structure is in an undened state. 168 = This routine cannot be called because a receive passthru operation is in progress on this command structure.
Page -11
169 = This routine cannot be called because a send passthru operation is in progress on this command structure. 170 = This routine cannot be called after ct_results() returns a result type of CS_DESCRIBE_RESULT. 171 = A cursor must be opened before this command type can be initialized. 172 = This routine cannot be called because the CS_COMMAND structure is in the middle of a send data operation. 173 = A return status of CS_PENDING must be returned from a completion callback if additional async operations have been initiated. 174 = A context structure must be supplied when setting/clearing this type of callback. 175 = There is not a callback handler installed for signal %1!. 176 = The server does not support null parameters of type %1!. 177 = The length of the null-terminated string parameter %1! exceeds the maxium length allowed. 178 = This routine cannot be called until at least one call to ct_send_data() has been made. 179 = A cursor row must be fetched before this command can be initialized. 180 = This command must come immediately after a CS_CURSOR_DECLARE command has been initialized. 181 = This command is not allowed when the cursor is closed. 182 = This command is not allowed after all the cursors rows have been fetched. If Layer = 2 (cslib user api layer), the meaning of Number is: 0 = No error. 1 = Unknown error. 2 = The information being retrieved will not t in a buffer of %1! bytes. 3 = Memory allocation failure. 4 = The parameter %1! cannot be NULL. 5 = When %1! is NULL the %2! parameter must be 0.
Page -12
6 = An illegal value of %1! was given for parameter %2!. 7 = The %1! parameter must be NULL. 8 = The %1! parameter must be set to CS_UNUSED. 9 = The property %1! cannot be set or cleared. 10 = An invalid locale pointer was passed in. 11 = The parameter %1! points to an illegal datatype value. 12 = An unknown locale name was passed in. 13 = A CS_GET operation cannot be performed on type %1!. 14 = Localization information could not be loaded. 15 = Error handling could not be initialized. 16 = Conversion between %1! and %2! datatypes is not supported. 17 = The format eld of a CS_DATAFMT structure should be CS_FMT_UNUSED when the datatype is %1!. 18 = An illegal value of %1! was placed in the %2! eld of the CS_DATAFMT structure. 19 = An illegal locale pointer was specied in the CS_DATAFMT structure. 20 = The conversion/operation resulted in overow. 21 = The conversion/operation resulted in underow. 22 = An illegal precision value was encountered. 23 = An illegal scale value was encountered. 24 = The conversion/operation was stopped due to a syntax error in the source eld. 25 = The datatype value is outside the domain of legal values for the datatype. 26 = A division by zero is not allowed. 27 = WARNING: Existing error and message handlers have been deinstalled. 28 = There was not enough memory available to save messages. All previously stored messages have been cleared. 29 = In-line error handling must be initialized with the CS_INIT operation before any other cs_diag() action may be taken. 30 = The message limit cannot be set to a value less than the number of CS-Library messages currently saved.
Page -13
31 = The context structure cannot be dropped because the application has not exited from %1!. 32 = When the type is CS_DT_CONFMT only a CS_SET operation is allowed. 33 = The requested translation is not supported. 34 = Some of the characters could not be translated. 35 = The conversion/operation stopped due to a style error. 36 = The result is truncated because the conversion/operation resulted in overow. 37 = cs_ctx_name failed to match the given keys. 38 = The string was not copied because this would result in overow. 39 = The string could not be built. An illegal place holder was found in the text string. 40 = Only 0, 1, or 2 stars are allowed in the format string. 41 = An unknown datatype token was found in the format string. 42 = The format string cannot be NULL. 43 = The custom format specier is too long. 44 = A custom format specier was not found to match the specier in the format string. 45 = Bad locale handler for cs_locale on types CS_SYB_LANG, CS_SYB_CHARSET or CS_SYB_LANG_CHARSET. 46 = Can not access localization le %1!. 47 = %1! Connection exception -- Connection does not exist. 48 = %1! Connection exception -- Connection name in use. 49 = %1! Invalid cursor name. 50 = %1! Invalid SQL statement identier. 51 = %1! cs_objects: error performing requested operation. 52 = An internal buffer overow occurs.
Page -14
If Layer = 3 (generic protocol layer), Number has no meaning. If Layer = 4 (protocol specic layer), the meaning of Number is: 1 = There is a tds protocol error. Premature end of the datastream was encountered. 2 = There is a tds protocol error. An illegal tds version was received. 3 = There is a tds protocol error. An illegal login status was received. 4 = There is a tds protocol error. There are too many bytes in the datastream. 5 = memory allocation failure. 6 = There is a tds protocol error. Duplicate ALT ID was seen while processing results. 7 = There is a tds protocol error. Invalid ALT operator was seen while processing results. 8 = There is a tds protocol error. Invalid ALT id was seen while processing results. 9 = There is a tds protocol error. Invalid ALT column count was seen while processing results. 10 = There is a tds protocol error. Invalid column number was seen while processing results. 11 = There is a tds protocol error. Invalid table index was seen while processing results. 12 = There is a tds protocol error. An illegal browse status was received. 13 = There is a tds protocol error. An illegal capability type was received. 14 = There is a tds protocol error. An invalid cursor name was received. 15 = There is a tds protocol error. A duplicate cursor id was received. 16 = There is a tds protocol error. An invalid cursor id was received. 17 = There is a tds protocol error. An invalid cursor row count was received.
Page -15
18 = There is a tds protocol error. An invalid cursor status was received. 19 = There is a tds protocol error. An invalid done status was received. 20 = There is a tds protocol error. An illegal DONEINPROC token stream was received. 21 = There is a tds protocol error. An invalid dynamic status was received. 22 = There is a tds protocol error. An invalid dynamic statement length was received. 23 = There is a tds protocol error. An invalid dynamic type was received. 24 = There is a tds protocol error. An invalid dynamic id was received. 25 = There is a tds protocol error. An invalid packet size was received. 26 = There is a tds protocol error. An illegal ENVCHANGE type was received. 27 = There is a tds protocol error. An invalid message status was received. 28 = There is a tds protocol error. An illegal token was received. 29 = There is a tds protocol error. An invalid option command was received. 30 = There is a tds protocol error. An invalid option type was received. 31 = There is a tds protocol error. An invalid orderby stream was received. 32 = There is a tds protocol error. A PARAMFMT was received with no parameters specied. 33 = There is a tds protocol error. An invalid PARAMFMT stream was received. 34 = There is a tds protocol error. A ROWFMT was received with no columns specied. 35 = There is a tds protocol error. An invalid ROWFMT stream was received. 36 = There is a tds state machine error. An illegal tds token sequence was received. Page -16
37 = There is a tds state machine error. Attempted operation with results pending. This is an internal error. 38 = There is a tds login error. Illegal number of parameters seen during negotiation. 39 = There is a tds protocol error. An invalid message id was received during login negotiation. 40 = There is a tds protocol error. An invalid column status was received. 41 = There is a tds protocol error. An invalid datatype was received. 42 = There is a tds protocol error. An invalid numeric precision was received. 43 = There is a tds protocol error. An invalid numeric scale was received. 44 = The attempt to connect to the server failed. 45 = There is an internal tds layer error. Access to the row buffer manager failed. 46 = There is a tds login error. An attempt was made by the server to encrypt a password, but no encryption handler was installed. 47 = There is a tds login error. The installed encryption handler returned a status that was not CS_SUCCEED. 48 = There is a tds login error. An attempt was made by the server to issue a security challenge, but no challenge handler was installed. 49 = There is a tds login error. The installed challenge handler returned a status that was not CS_SUCCEED. 50 = There is an internal tds layer error. An error was returned from the server while processing an internal tds stream. 51 = There is an internal tds layer error. An unexpected error was returned from common library. 52 = There is an internal tds layer error. An unexpected error was returned from the async manager. If Layer = 5 (network packet layer), the meaning of Number is: 1 = There was an error encountered while closing the connection. 2 = There was an error encountered while releasing the address. 3 = There was an error encountered while resolving the address.
Page -17
4 = There was an error encountered while establishing the connection. 5 = There was an error encountered while executing the expedited write. 6 = There was an error while executing the network read. 7 = There was an error while executing the network write. 8 = There was an error encountered while opening the address dictionary. 9 = There was an error encountered while closing the address dictionary. 10 = A read was attempted on a connection already executing a read. 11 = A write was attempted on a connection already executing a write. 12 = State error: trying to write when connection is expecting a read. 13 = State error: trying to read when connection is expecting a write. 14 = Buffer is too small to t a whole packet. 15 = Reading from the network while there remains unprocessed data from the last read. 16 = There was an error encountered while getting the address information. 17 = There was an error encountered while getting the address property. 18 = There is a protocol packet error. An illegal length was received 128 = There was an error encountered while initializing network options recordkeeping. 129 = There was an error encountered while setting a network option. 130 = unused. 131 = There was an error encountered while initializing NetLibrary. 132 = There was an error encountered while initializing Net-Library engine.
Page -18
133 = There was an error encountered while setting Net-Library callback. 134 = There was an error encountered while exiting Net-Library engine. 135 = There was an error encountered while exiting Net-Library. 136 = There was an error encountered while setting Net-Library callback mode. 137 = There was an error encountered while chaining signals in NetLibrary.
Page -19
Page -20
Sample Code for Error Handling
D.
This appendix contains sample error handling code for Embedded SQL/C, Embedded SQL/COBOL, and Client-Library. You can use these examples to help you write your own error handling code. You can nd additional sample programs in the Technical Documents collection of Technical Library on the Web. To access the Technical Library Web site, go to support.sybase.com, then go to the Support Services tab and select the link to Technical Documents. Search the collection for these TechNote titles: Client-Library Sample Programs Embedded SQL/C Sample Programs Embedded SQL/COBOL Sample Programs
Open Client and Open Server Program Disclaimer

The Open Client and Open Servers applications and code in this document have been created to provide ideas and help working with Sybase connectivity libraries. Please read this disclaimer before using the code: This code is being distributed free of charge. It is not a Sybase product, is not supported by sybase, and is provided as-is without warranty of any kind. Sybase disclaims all warranties or conditions, either express or implied, including without limitation any implied warranties of merchantability, merchantable quality, noninfringement and tness for a particular purpose (whether arising by statute or in law or as a result of a course of dealing or usage of trade). In no event shall Sybase be liable for loss of prots or loss of data or any damages whatsoever including without limitation direct, indirect, incidental, consequential or special damages, even if Sybase has been advised of the possibility of such damages. ctlib_client_msg_handler(ctx, conn, client_msgtxt)
Embedded SQL/C Error Handler

The following is a code fragment for handling errors in an Embedded SQL/C application:
Page -1
/* .... /* Declare the SQLCA */ EXEC SQL INCLUDE sqlca; #define ERREXIT -1 /* Forward declarations of the error and message handlers */ int error_handler(); int warning_handler();
int main() { ..... EXEC SQL WHENEVER SQLERROR CALL error_handler(); EXEC SQL WHENEVER NOT FOUND CONTINUE ; EXEC SQL WHENEVER SQLWARNING CALL warning_handler(); ..... exit(0); }
/* ** void error_handler() ** **Displays error codes and numbers from the SQLCA and exits with **an ERREXIT status. */ void error_handler() { fprintf(stderr, \n** SQLCODE=(%d), sqlca.sqlcode); if (sqlca.sqlerrm.sqlerrml) { fprintf(stderr, \n** %s, sqlca.sqlerrm.sqlerrmc); } fprintf(stderr, \n\n); exit(ERREXIT); } /* ** void warning_handler() **
Page -2
**Displays warning messages. */ void warning_handler() { if (sqlca.sqlwarn[1] == W) { fprintf(stderr, \n** Data truncated.\n); } if (sqlca.sqlwarn[3] == W) { fprintf(stderr, \n** Insufficient host variables to store results.\n); } return; } ** void error_handler() ** **Displays error codes and numbers from the SQLCA and exits with **an ERREXIT status. */ void error_handler() { fprintf(stderr, "\n** SQLCODE=(%d)", sqlca.sqlcode); if (sqlca.sqlerrm.sqlerrml) { fprintf(stderr, "\n** SQL Server Error "); fprintf(stderr, "\n** %s", sqlca.sqlerrm.sqlerrmc); } fprintf(stderr, "\n\n"); exit(ERREXIT); } /* ** void warning_handler() ** **Displays warning messages. */ void warning_handler() {
Page -3
if (sqlca.sqlwarn[1] == 'W') { fprintf(stderr, "\n** Data truncated.\n"); } if (sqlca.sqlwarn[3] == 'W') { fprintf(stderr, "\n** Insufficient host variables to store results.\n"); } return; }
Embedded SQL/COBOL Error Handler

The following is a code fragment for handling errors in an Embedded SQL/COBOL application:
....... EXEC SQL INCLUDE SQLCA END-EXEC. ....... EXEC SQL WHENEVER SQLERROR PERFORM ERR-PARA END-EXEC EXEC SQL WHENEVER SQLWARNING PERFORM WARN-PARA END-EXEC EXEC SQL WHENEVER NOT FOUND CONTINUE END-EXEC. ....... ************************************************************* WARN-PARA. DISPLAY "Warning code is " SQLCODE. DISPLAY "Warning message is " SQLERRMC. IF SQLWARN2 EQUAL "W" DISPLAY "A null value was eliminated from the argument " set of a function.". IF SQLWARN3 EQUAL "W" DISPLAY "An into clause had too many or too few host " variables.". IF SQLWARN4 EQUAL "W" DISPLAY "A dynamic update or delete was lacking a " where clause.". IF SQLWARN5 EQUAL "W" DISPLAY "A server conversion or truncation error " occurred.". WARN-PARA-END. EXIT.
Page -4
************************************************************* ERR-PARA. * * print the error code and the error message * DISPLAY "Error code is " SQLCODE. DISPLAY "Error message is " SQLERRMC. STOP RUN. *************************************************************
Client-Library Error Handler

The following is a code fragment for handling errors in a ClientLibrary application:
/* ctlib_client_msg_handler ** print any client library warning or ** error message. By default return a ** CS_SUCCEED, so we do not mark the ** connection as dead. */ CS_RETCODE CS_PUBLIC ctlib_client_msg_handler (ctx, conn, client_msgtxt) CS_CONTEXT *ctx; CS_CONNECTION *conn; CS_CLIENTMSG *client_msgtxt; { fprintf(stderr, "\nOPEN CLIENT ERROR MESSAGE"); fprintf(stderr, "\nnumber: layer (%ld), origin (%ld)", CS_LAYER(client_msgtxt->msgnumber), CS_ORIGIN(client_msgtxt->msgnumber)); fprintf(stderr, "\ntext:\n%s", client_msgtxt->msgstring); if (client_msgtxt->osstringlen > 0) fprintf(stderr, "\nOS error : %s", client_msgtxt->osstring); fprintf(stderr, "\nERROR HANDLER OUTPUT ENDS\n"); fflush(stderr); return(CS_SUCCEED); } /* ctlib_server_msg_handler ** print any server error message.
Page -5
*/ CS_RETCODE CS_PUBLIC ctlib_server_msg_handler (ctx, conn, srvr_msgtxt) CS_CONTEXT *ctx; CS_CONNECTION *conn; CS_SERVERMSG *srvr_msgtxt; { fprintf(stderr, "\nSERVER MESSAGE"); if (srvr_msgtxt->svrnlen > 0) fprintf(stderr, " from server '%s'", srvr_msgtxt->svrname); if (srvr_msgtxt->proclen > 0) fprintf(stderr, " at procedure '%s'", srvr_msgtxt->proc); fprintf(stderr, "\nnumber (%ld), severity (%ld)", srvr_msgtxt->msgnumber, srvr_msgtxt->severity); fprintf(stderr, "\nstate (%ld), line (%ld)", srvr_msgtxt->state, srvr_msgtxt->line); fprintf(stderr, "\ntext:\n%s", srvr_msgtxt->text); fprintf(stderr, "\nMESSAGE HANDLER OUTPUT ENDS\n"); fflush(stderr); return(CS_SUCCEED); }
Page -6
Sample Code for Handling Large Text and Image Data

The following are sample programs for Embedded SQL which demonstrate the use of host variables in handling large text and image data.
E.
You can nd additional sample programs in the Technical Documents collection of Technical Library on the Web. To access the Technical Library Web site, go to support.sybase.com, then go to the Support Services tab and select the link to Technical Documents. Search the collection for these TechNote titles: Client-Library Sample Programs Embedded SQL/C Sample Programs Embedded SQL/COBOL Sample Programs
text_image.sql
Use this script to create the table text_tab which you will use to run the sample program in the following section:
use tempdb go if exists (select 1 from sysobjects where name = text_tab and type = U ) drop table text_tab go create table text_tab ( text_col text null, image_col image null) go
Page -1
text_image.cp
/* Program name: text_image.cp ** ** Description: Inserting text and image data using host ** variables of types CS_TEXT and CS_IMAGE. ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** */ Notes: This is a new feature in 11.x which allows you to use host variables of type CS_TEXT and CS_IMAGE in insert or update statements to handle text or image data. You dont need to use to mixed-mode client-library programming or dynamic sql, which had a limit of 64 k bytes. The size of the text or image data that can now be sent is limited only by memory or the maximum size allowed for text and image data by the SQL Server. However, the larger the data being sent this way, the slower the performance. Script file: text_image.sql Notes: Make sure you compile the program using the '-y' precompiler flag.
#include <stdio.h> #include "sybsqlex.h" /* Declare the SQLCA */ EXEC SQL INCLUDE sqlca; /* ** Forward declarations of the error and message handlers and ** other subroutines called from main(). */ void error_handler(); void warning_handler();
int main() { int i=0; EXEC SQL BEGIN /* storage for CS_CHAR CS_TEXT CS_IMAGE DECLARE SECTION; login name and password */ username[30], password[30]; text_var[10000]; image_var[10000];
Page -2
EXEC SQL END DECLARE SECTION; EXEC SQL WHENEVER SQLERROR CALL error_handler(); EXEC SQL WHENEVER SQLWARNING CALL warning_handler(); EXEC SQL WHENEVER NOT FOUND CONTINUE; /* ** Copy the user ** the variables */ strcpy(username, strcpy(password,
name and password defined in sybsqlex.h to declared for them in the declare section. USER); PASSWORD);
/* Connect to the server and specify the database to use */ EXEC SQL CONNECT :username IDENTIFIED BY :password; EXEC SQL USE tempdb; /* Put something interesting in the variables. */ for (i=0; i< 10000; i++ ) { text_var[i] = 'a'; image_var[i] = '@'; } EXEC SQL INSERT text_tab VALUES(:text_var, :image_var); if ( sqlca.sqlcode == 0 ) { printf("Row successfully inserted! \n"); EXEC SQL COMMIT WORK ; } EXEC SQL DISCONNECT ALL; exit(0); }
/* ** void error_handler() ** ** Displays error codes and numbers from the SQLCA and exits with ** an ERREXIT status. */ void error_handler() { fprintf(stderr, "\n** SQLCODE=(%d)", sqlca.sqlcode); if (sqlca.sqlerrm.sqlerrml)
Page -3
{ fprintf(stderr, "\n** Error Message: "); fprintf(stderr, "\n** %s", sqlca.sqlerrm.sqlerrmc); } fprintf(stderr, "\n\n"); exit(ERREXIT); } /* ** void warning_handler() ** ** Displays warning messages. */ void warning_handler() { if (sqlca.sqlwarn[1] == 'W') { fprintf(stderr, "\n** Data truncated.\n"); } if (sqlca.sqlwarn[3] == 'W') { fprintf(stderr, "\n** Insufficient host variables to store results.\n"); } return; }
text_image.pco
IDENTIFICATION DIVISION. PROGRAM-ID. EXAMPLE1. ENVIRONMENT DIVISION. CONFIGURATION SECTION. SOURCE-COMPUTER. xyz. OBJECT-COMPUTER. xyz. DATA DIVISION. WORKING-STORAGE SECTION. * text_image.pco * This program uses text and image types (new to 11.1) * to insert large text and image values into the database.
Page -4
* * * * * *
NOTE: The entire buffer of image and text data is sent to the server regardless of content. The size of the buffer is determined by its ESQL declaration. It is therefore important to declare only the size that you need for these datatypes. You must pre-compile with the -y flag to use this feature. EXEC SQL INCLUDE SQLCA END-EXEC. EXEC SQL BEGIN DECLARE SECTION END-EXEC .
* userid and password 01 01 UID PASS PIC X(30). PIC X(30).
*input from database 01 01 TEXT-VAR IMG-VAR PIC X(20) USAGE IS CS-TEXT. PIC X(20) USAGE IS CS-IMAGE.
EXEC SQL END DECLARE SECTION END-EXEC.
PROCEDURE DIVISION. P0. EXEC SQL WHENEVER SQLERROR PERFORM ERR-PARA END-EXEC. EXEC SQL WHENEVER SQLWARNING PERFORM WARN-PARA END-EXEC. EXEC SQL WHENEVER NOT FOUND CONTINUE END-EXEC. * NOTE: fill in your user name and password here. MOVE "sa" TO UID. MOVE "" TO PASS. EXEC SQL CONNECT :UID IDENTIFIED BY :PASS END-EXEC. EXEC SQL USE tempdb END-EXEC. * Fill up the text and image structure. MOVE "HELLO WORLD" TO TEXT-VAR. MOVE "0X12345" TO IMG-VAR. EXEC SQL INSERT text_tab VALUES(:TEXT-VAR, :IMG-VAR)END-EXEC EXEC SQL COMMIT WORK END-EXEC. STOP RUN.
Page -5
************************************************************* WARN-PARA. DISPLAY "Warning code is " SQLCODE. DISPLAY "Warning message is " SQLERRMC. IF SQLWARN1 EQUAL "W" DISPLAY "Data has been truncated.". IF SQLWARN2 EQUAL "W" DISPLAY "A null value was eliminated from the argument " set of a function.". IF SQLWARN3 EQUAL "W" DISPLAY "An into clause had too many or too few host " variables.". IF SQLWARN4 EQUAL "W" DISPLAY "A dynamic update or delete was lacking a where" clause.". IF SQLWARN5 EQUAL "W" DISPLAY "A server conversion or truncation error " occurred.". WARN-PARA-END. EXIT. ************************************************************* ERR-PARA. * * print the error code, the error message and the line number of * the command that caused the error. * DISPLAY "Error code is " SQLCODE. DISPLAY "Error message is " SQLERRMC. STOP RUN. *************************************************************
Page -6

Error Guide

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Error Guide

Încărcat de

Drepturi de autor:

Formate disponibile

Open Client Error Messages Guide

2. Embedded SQL/C and COBOL Error Messages

3. Client Library Error Messages

Title for Your Books Footers

Product Name & Version Number

4. DB-Library Error Messages

Product Name & Version Number

Title for Your Books Footers

Product Name & Version Number

How to Find Error Information

Which Errors Are Documented?

How Do I Locate the Error Message I Need?

is represented in this manual as:

Open Client Error Messages Guide

Open Client 10.x and 11.x

Other Sources of Information

Open Client 10.x and 11.x

If You Need Help

Open Client Error Messages Guide

Open Client 10.x and 11.x

BCP and Bulk Library Errors Messages

Open Client Error Messages Guide

Open Client 10.x and 11.x

Memory allocation failed

Open Client 10.0.x

BCP and Bulk Library Errors Messages

Open Client 10.x and 11.x

Open Client Error Messages Guide

Open Client 10.x and 11.x

Front end does not support this feature

BCP and Bulk Library Errors Messages

Open Client 10.x and 11.x

Open Client Error Messages Guide

Open Client 10.x and 11.x

Bulk login property must be set

BCP and Bulk Library Errors Messages

Open Client 10.x and 11.x

Open Client Error Messages Guide

Open Client 10.x and 11.x

Unknown datatype encountered

BCP and Bulk Library Errors Messages

Open Client 10.x and 11.x

Open Client Error Messages Guide

Open Client 10.x and 11.x

Conversion stopped due to syntax error

BCP and Bulk Library Errors Messages

Open Client 10.x and 11.x

The bcp format le contains this denition:

Open Client Error Messages Guide

Open Client 10.x and 11.x

10.0 3 1SYBCHAR015"-"1col1 2SYBCHAR015"-"2col2 3SYBCHAR08"\n"3col3

BCP and Bulk Library Errors Messages

Open Client 10.x and 11.x

Unknown version of bcp format-le

Use format le version:

Open Client Error Messages Guide

Open Client 10.x and 11.x

Unexpected EOF encountered

BCP and Bulk Library Errors Messages

Open Client 10.x and 11.x

Bulk Library 10.x and later

Open Client Error Messages Guide

Open Client 10.x and 11.x