FreeTDS Development Group

["沈勇" <shen_yong_cn AT 163.com>]

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