contains all information needed by db-lib to manage communications with the server.

srctype

datatype of the data to convert.

src

buffer to convert

srclen

length of src

desttype

target datatype

dest

output buffer

destlen

size of dest

Returns:

On success, the count of output bytes in dest, else -1. On failure, it will call any user-supplied error handler.

Remarks:

Causes of failure:

No such conversion unavailable.

Character data output was truncated, or numerical data overflowed or lost precision.

In converting character data to one of the numeric types, the string could not be interpreted as a number.

Conversion functions are handled in the TDS layer.

The main reason for this is that ct-lib and ODBC (and presumably DBI) need to be able to do conversions between datatypes. This is possible because the format of complex data (dates, money, numeric, decimal) is defined by its representation on the wire; thus what we call DBMONEY is exactly its format on the wire. CLIs that need a different representation (ODBC?) need to convert from this format anyway, so the code would already be in place.

Each datatype is also defined by its Server-type so all CLIs should be able to map native types to server types as well.

tds_convert() copies from src to dest and returns the output data length, period. All padding and termination is the responsibility of the API library and is done post-conversion. The peculiar rule in dbconvert() is that a destlen of -1 and a desttype of SYBCHAR means the output buffer should be null-terminated.

When row buffering is enabled (DBBUFFER option is on), the client can use dbgetrow() to re-read a row previously fetched with dbnextrow(). The effect is to move the row pointer -- analogous to fseek() -- back to row. Calls to dbnextrow() read from row + 1 until the buffer is exhausted, at which point it resumes its normal behavior, except that as each row is fetched from the server, it is added to the row buffer (in addition to being returned to the client). When the buffer is filled, dbnextrow() returns FAIL until the buffer is at least partially emptied with dbclrbuf().

Parameters:

dbproc

contains all information needed by db-lib to manage communications with the server.

If none of the above are present, dbresults() returns NO_MORE_RESULTS.

SUCCEED does not imply that DBROWS() will return TRUE or even that dbnumcols() will return nonzero. A general algorithm for reading results will call dbresults() until it return NO_MORE_RESULTS (or FAIL). An application should check for all the above kinds of results within the dbresults() loop.

contains all information needed by db-lib to manage communications with the server.

ptr

address of client-defined data.

Remarks:

ptr is the location of user data that db-lib will associate with dbproc. The client allocates the buffer addressed by ptr. db-lib never examines or uses the information; it just stashes the pointer for later retrieval by the application with dbgetuserdata().