[freetds] Error of "bigint" datatype of MSSql2000

=?GB2312?Q?=C9=F2=D3=C2?= shen_yong_cn at 163.com
Thu Oct 9 09:13:49 EDT 2003


Thompson, Bill D (London),=C4=FA=BA=C3=A3=A1

=09I am using freetds-0.61.tgz from the download from the=
 freetds.org.
=09The source version of this tar ball is 0.61.1.
=09
=09But how can I get the right version?

=09

=3D=3D=3D=3D=3D=3D=3D 2003-10-08 10:56:00 =C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=C0=A3=BA=3D=3D=3D=3D=3D=3D=3D

>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:=09shen_yong_cn at 163.com [SMTP:shen_yong_cn at 163.com]
>> Sent:=0908 October 2003 10:43
>> To:=09FreeTDS Development Group; FreeTDS Development Group
>> Subject:=09[freetds] Error of "bigint" datatype of MSSql2000
>> 
>> Thompson, Bill D (London),=C4=FA=BA=C3=A3=A1
>> =09
>> =09hello. I have used the code like this to bind all columns of=
 the
>> resultset;
>> =09but the columns of data type "bigint" in SqlServer 2000=
 faild.
>> =09ct_desribe return's the _columns[i].datatype is 0.
>> =09why??
>> 
>> bool ResultSet :: bind()  
>> {  
>>     CS_INT col_num,ret_size;  
>>     _ret =3D  
>>  
>>=
 ct_res_info(_command,CS_NUMDATA,&col_num,sizeof(col_num),&ret_si=
ze);  
>>     if (_ret !=3D CS_SUCCEED)  
>>         return false;  
>>       
>>     for(int i =3D 0;i< col_num; i++)  
>>     {  
>>         _ret =3D ct_describe(_command,i+1,&_columns[i]);  
>>         if (_ret !=3D CS_SUCCEED)  
>>             return false;  
>>         _values[i].setType(_columns[i].datatype);  
>>   
>>         _ret =3D ct_bind(_command,i+1,&_columns[i],  
>>                        _values[i].getValue(),&_datalength[i], =
 
>>                        &_indicator[i]);  
>>         if (_ret !=3D CS_SUCCEED)   
>>             return false;  
>>     }  
>>     _binded =3D true;  
>> }  
>>  
>> 
>> =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
>> 
>> >Hi,
>> >
>> >I've been doing some work on cursors recently. 
>> >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. 
>> >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. 
>> >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 
>> >    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
>> 
>> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D
>> =09=09=09
>> 
>> =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D6=C2
>> =C0=F1=A3=A1
>>  
>> =09=09=09=09 
>> =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
>> 
>> 
>> _______________________________________________
>> FreeTDS mailing list
>> FreeTDS at lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>
>_______________________________________________
>FreeTDS mailing list
>FreeTDS at lists.ibiblio.org
>http://lists.ibiblio.org/mailman/listinfo/freetds

=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D
=09=09=09

=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D6=C2
=C0=F1=A3=A1
 
=09=09=09=09 
=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-09





More information about the FreeTDS mailing list