[freetds] Error of "bigint" datatype of MSSql2000

=?GB2312?Q?=C9=F2=D3=C2?= shen_yong_cn at 163.com
Wed Oct 8 18:43:15 EDT 2003


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




More information about the FreeTDS mailing list