Skip to Content.
Sympa Menu

freetds - Re: RE: [freetds] Error of "bigint" datatype of MSSql2000

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "沈勇" <shen_yong_cn AT 163.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: RE: [freetds] Error of "bigint" datatype of MSSql2000
  • Date: Thu, 9 Oct 2003 8:13:49 +0800

Thompson, Bill D (London),您好!

I am using freetds-0.61.tgz from the download from the freetds.org.
The source version of this tar ball is 0.61.1.

But how can I get the right version?



======= 2003-10-08 10:56:00 您在来信中写道:=======

>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
>>
>> Thompson, Bill D (London),您好!
>>
>> 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??
>>
>> bool ResultSet :: bind()
>> {
>> CS_INT col_num,ret_size;
>> _ret =
>>
>> ct_res_info(_command,CS_NUMDATA,&col_num,sizeof(col_num),&ret_size);
>> if (_ret != CS_SUCCEED)
>> return false;
>>
>> for(int i = 0;i< col_num; i++)
>> {
>> _ret = ct_describe(_command,i+1,&_columns[i]);
>> if (_ret != CS_SUCCEED)
>> return false;
>> _values[i].setType(_columns[i].datatype);
>>
>> _ret = ct_bind(_command,i+1,&_columns[i],
>> _values[i].getValue(),&_datalength[i],
>> &_indicator[i]);
>> if (_ret != CS_SUCCEED)
>> return false;
>> }
>> _binded = true;
>> }
>>
>>
>> ======= 2003-10-08 10:18:00 您在来信中写道:=======
>>
>> >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,
>> >
>> >
>> >ず�`昂��,父,�ず�`昂��ず�`昂��,父,�ず�`昂��ず�`昂��,父,��
>> >
>> >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
>>
>> = = = = = = = = = = = = = = = = = = = =
>>
>>
>>         致
>> 礼!
>>
>>
>>         沈勇
>>         shen_yong_cn AT 163.com
>>           2003-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

= = = = = = = = = = = = = = = = = = = =


        致
礼!


        沈勇
        shen_yong_cn AT 163.com
          2003-10-09







Archive powered by MHonArc 2.6.24.

Top of Page