Skip to Content.
Sympa Menu

freetds - RE: [freetds] RE: textptr size in blob field

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] RE: textptr size in blob field
  • Date: Thu, 25 Mar 2004 16:48:36 -0500

> 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.






Archive powered by MHonArc 2.6.24.

Top of Page