[freetds] Error of "bigint" datatype of MSSql2000
Thompson, Bill D (London)
bill_d_thompson at ml.com
Wed Oct 8 11:56:33 EDT 2003
Hi,
As far as I know , support for bigint datatypes only introduced =
relatively
recently in freetds.
So, either you are not using an up to date version of the code or the =
job
was not properly done in ctlib
which freetds are you using ?
Bill
> -----Original Message-----
> From: shen_yong_cn at 163.com [SMTP:shen_yong_cn at 163.com]
> Sent: 08 October 2003 10:43
> To: FreeTDS Development Group; FreeTDS Development Group
> Subject: [freetds] Error of "bigint" datatype of MSSql2000
>=20
> Thompson, Bill D (London),=C4=FA=BA=C3=A3=A1
> =09
> hello. I have used the code like this to bind all columns of the
> resultset;
> but the columns of data type "bigint" in SqlServer 2000 faild.
> ct_desribe return's the _columns[i].datatype is 0.
> why??
>=20
> bool ResultSet :: bind() =20
> { =20
> CS_INT col_num,ret_size; =20
> _ret =3D =20
> =20
> ct_res_info(_command,CS_NUMDATA,&col_num,sizeof(col_num),&ret_size); =
> if (_ret !=3D CS_SUCCEED) =20
> return false; =20
> =20
> for(int i =3D 0;i< col_num; i++) =20
> { =20
> _ret =3D ct_describe(_command,i+1,&_columns[i]); =20
> if (_ret !=3D CS_SUCCEED) =20
> return false; =20
> _values[i].setType(_columns[i].datatype); =20
> =20
> _ret =3D ct_bind(_command,i+1,&_columns[i], =20
> _values[i].getValue(),&_datalength[i], =20
> &_indicator[i]); =20
> if (_ret !=3D CS_SUCCEED) =20
> return false; =20
> } =20
> _binded =3D true; =20
> } =20
> =20
>=20
> =3D=3D=3D=3D=3D=3D=3D 2003-10-08 10:18:00 =
=C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=C0=A3=BA=3D=3D=3D=3D=3D=3D=3D
>=20
> >Hi,
> >
> >I've been doing some work on cursors recently.=20
> >I have implemented the basic cursor functionality in the tds =
library, and
> >implemented the appropriate functions in ct-library.
> >The protocol issues are pretty much sorted. I've implemented the TDS =
5.0
> >messages which enable the client to access server side cursors on =
Sybase,
> >and also the calls to the undocumented SQL server "stored =
procedures"
> which
> >provide the same functionality on that platform.
> >
> >There's one fairly major shortcoming in what I've done however, and =
I
> don't
> >want to go any further without a discussion.
> >
> >The implementation of cursors allows the client to maintain more =
than one
> >stream of processing on a single connection.
> >So, using cursors, you would be able to:
> >
> >* open a cursor to select data from the database
> >* fetch a row or rows from the cursor.
> >* use the returned data as the basis of other queries or updates
> >* fetch more rows from the cursor
> >....
> >
> >Previously, this type of processing was only possible if you opened =
up
> more
> >than one connection to the database.
> >
> >This presents freetds with a bit of problem, and it's to do with the =
way
> we
> >process and store the results metadata.
> >
> >Currently, we store the results metadata in the tsd_socket =
structure,
> which
> >is associated with a database connection.
> >
> >This implementation was fine when we could only have one stream of
> >processing on a connection, i.e.
> >
> >1. submit sql batch (which might contain multiple statements)
> >2. While no more results
> > 2.1 receive and store results metadata
> > 2.2 receive and process data relating to the result set
> > 2.3 receive and store "end" data
> >
> >We knew pretty much that a given connection would only have to =
handle one
> >set of results metadata at a time.
> >Each time we received a new set of results metdata, we could safely
> discard
> >the last set and start afresh.
> >
> >A while back, we stretched the limits of this model to handle =
"compute"
> >data, and output parameters from stored procedures.=20
> >If a query contained one or more "compute" clauses, then the server =
would
> >return multiple sets of result metadata - one for the main query =
results,
> >and one for each compute clause.=20
> >Fortunately for us the result metadata for a compute clause is =
identified
> as
> >such within the TDS protocol. This allowed us to handle and store =
this
> >result information separately from the main result set data.
> >Return paramaters from stored procedures were a similar challenge, =
but
> again
> >we could easily identify these and store them separately.
> >
> >As a result, we now have the following in the tds_socket structure :
> >
> >TDSRESULTINFO *curr_resinfo; /* pointer to one of the below... =
*/
> >TDSRESULTINFO *res_info; /* "main" results metadata =
*/
> >TDS_INT num_comp_info; /* number of compute results */
> >TDSCOMPUTEINFO **comp_info; /* array of compute results metadata */
> >TDSPARAMINFO *param_info; /* parameter results metadata */
> >
> >With the advent of cursors, two key facts conspire to finally break =
our
> >processing, I believe...
> >
> >1. The results metadata received from an "open cursor" operation is
> >indistinguishable from the=20
> > results metadata received from a straightforward query.
> >
> >2. The results metadata is handled and stored by the "tds" layer in =
our
> >code, which is essentially
> > "blind" to the context in which those results are received.
> >
> >I am coming to the conclusion that the storage of the results =
metadata
> >should be controlled by the API layers within freetds.
> >
> >I can envisage a new model where :
> >
> >tds_process_result_tokens, when it reads a set of results metadata,
> >allocates the storage for that data, but returns the storage to the
> calling
> >function for management.
> >If an API function, say ct_results or dbresults is calling
> >tds_process_result_tokens, it could then save the allocated results
> >structure to it's own control structure - the DBPROCESS structure =
for
> >dblibrary or the CS_COMMAND structure for ctlibrary
> >If an internal function such as tds_set_spid or =
tds_process_simple_query
> is
> >calling tds_process_result_tokens, it could hold the results data
> >temporarily.
> >
> >tds_process_row_tokens, when called to retrieve a data row, could be
> passed
> >the appropriate results metadata structure to allow it to interpret =
the
> >"row" data correctly.
> >
> >I'm still in the process of thinking this through (as I'm sure you =
can
> >tell), but I'd appreciate any feedback or ideas.
> >
> >Best wishes,
> >
> >
> =
>=A4=BA=B0`=B0=BA=A4=F8,=B8=B8,=F8=A4=BA=B0`=B0=BA=A4=F8=A4=BA=B0`=B0=BA=
=A4=F8,=B8=B8,=F8=A4=BA=B0`=B0=BA=A4=F8=A4=BA=B0`=B0=BA=A4=F8,=B8=B8,=F8=
=A4
> >
> >Bill Thompson
> >Securities Services Division
> >Merrill Lynch Europe
> >
> >For very important information relating to this e-mail please click =
on
> this
> >link: http://www.ml.com/legal_info.htm
> >
> >
> >
> >_______________________________________________
> >FreeTDS mailing list
> >FreeTDS at lists.ibiblio.org
> >http://lists.ibiblio.org/mailman/listinfo/freetds
>=20
> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D =3D =3D
> =09
>=20
> =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D6=C2
> =C0=F1=A3=A1
> =20
> =20
> =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=C9=F2=D3=C2
> =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1shen_yong_cn at 163.com
> =
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12003-10-08
>=20
>=20
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
More information about the FreeTDS
mailing list