FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: M C [mailto:mcbp223 AT yahoo.com]
> Sent: March 25, 2004 1:12 PM
> 
> > > > I am playing with Query Analizer as a server emulator.
> > > For blobs, it will accept arbitrary lengths for textptr, less 
> > > than 256 of coarse (my tests were with the MS odbc driver and 
> > > oledb provider so far).
> > > Would you please check the hardcoding in token.cpp,  function 
> > > tds_get_data(), by the line
> > >     if (len == 16) { /*  Jeff's hack */
> > >         tds_get_n(tds, blob_info->textptr, 16);
> > > 
> > > and see if you can afford a dynamic size for that?
> > > I'm not sure if you want to go for the allocation overhead 
> > > though, but some strategy with optimization for len <= 16 
> might work.
> > > Thanks,
> > > MC
> > >  
> > 
> > ??? how did you send length for textptr ???
> > textptr is not the content of text...
> > 
> > freddy77
> 
> The byte preceeding textptr in the blob is it's length. It is 
> gotten in tds_get_data(),
>         switch (curcol->column_varint_size) {
>         case 4:  /* Its a BLOB... */
> ---->           len = tds_get_byte(tds);
>                 blob_info = (TDSBLOBINFO *) & 
> (current_row[curcol->column_offset]);
> ---->           if (len == 16) { /*  Jeff's hack */
>                         tds_get_n(tds, blob_info->textptr, 16);
>                         tds_get_n(tds, blob_info->timestamp, 8);
> 
> But tested only against 16 in the if (len == 16).

MC, 

Let me make sure I understand your point.  

Columns whose varint_size is 4 may be of several datatypes, including 
SYBVARIANT and SYBLONGBINARY.  If it's not one of those we assume (probably a 
little unsafely) that it's SYBTEXT/SYBIMAGE.  In that case, we know the TDS 
stream won't have 4 bytes of data, but will instead have a 1-byte prefix 
describing the ensuing bytes.  

We read the byte an examine it.  If its value is 16, we next read:

        1.  a 16-byte textptr handle
        2.  an 8-byte timestamp
        3.  a 4-byte integer, the column size

else we set the column size to 0.  

You're saying the textptr is not always 16 bytes, that it may be anywhere 
from 1 to 256.  You're looking at our data structure:

        typedef struct tds_blob
        {
                TDS_CHAR *textvalue;
                TDS_CHAR textptr[16];
                TDS_CHAR timestamp[8];
        } TDSBLOB;

and asking if we could have "TDS_CHAR* textptr".  I think I'd be inclined to 
make it:

        typedef struct tds_blob
        {
                TDS_CHAR *textvalue;
                TDS_TINYINT textptrlen;
                TDS_CHAR textptr[256];
                TDS_CHAR timestamp[8];
        } TDSBLOB;

instead.  The logic to allocate and free those bytes would otherwise be 
almost much as the 256 we're trying to save.  

Do you know a way to coerce the server into sending differently sized 
textptr's?  If not, do you have  an example, in a trace or TDSDUMP log?   I 
would expect things to fall apart pretty quickly, because the TDS stream 
would be misinterpreted.  

> I take it that textptr works like a bookmark, the server can 
> send anything and the client will send back the same thing 
> when asking for a chunk.

I think that's right.  

Regards, 

--jkl

P.S., What's your name, or do you like to be called "MC"?  


-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.
If you, as the intended recipient of this message, the purpose of which is to 
inform and update our clients, prospects and consultants of developments 
relating to our services and products, would not like to receive further 
e-mail correspondence from the sender, please "reply" to the sender 
indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New York, 
NY 10105.