[freetds] Server - Problems with TDS 4.2 COLFMT token
James K. Lowden
jklowden at schemamania.org
Fri May 14 18:10:23 EDT 2004
On Fri, 14 May 2004, Steve Kirkendall <skirkendall at dsl-only.net> wrote:
> "James K. Lowden" <jklowden at schemamania.org> wrote on Friday, May 14,
> > OK, first you send 0xA0, from which the client derives the number of
> > columns. That looks fine, and, you're right, the information is not
> > repeated in the next packet.
> Got it! There's a bug in src/server/server.c:tds_send_col_name()
> -- it's sending the NUL byte at the end of each column name. On
> the receiving end, tds_process_col_name() reads a 1-byte length,
> and then the characters of the name itself but not the NUL. Then,
> in the next loop iteration, it misinterprets the NUL character
> as a 0 length byte. Consequently, it ends up thinking there are
> twice as many columns as there really are.
Excellent! Chalk up one for the good guys.
> But it *is* wrong.
I have to wonder how it ever worked.
> I hope to get my altered versions of the server functions cleaned
> up and submitted this weekend. That's kind of important, because
> my available time for this tiny server project has just about ended.
I guess "tiny" refers to the server? ;-)
> > col name type size varies
> > ------ ------------------ -------- ------ ------
> > - 14 MINIMUM_SCALE smallint 2 1
> > - 15 MAXIMUM_SCALE smallint 2 1
> > - 16 SQL_DATA_TYPE smallint 2 0
> > - 17 SQL_DATETIME_SUB smallint 2 1
> > - 18 NUM_PREC_RADIX int 4 1
> > - 19 INTERVAL_PRECISION smallint 2 1
> > - 20 USERTYPE smallint 2 1
> Do you know what SQL_DATETIME_SUB and INTERVAL_PRECISION
> should be? I've had some trouble getting TIMESTAMP data types to
> display correctly, and they sound like they might be relevant.
I'm not sure how to answer those questions.
That's the log of my query. Tell me if you need more.
This is quite a cool thing you're doing. Some years ago, when OLE was
hot, I wrote an OleDB server: it offered library output as "tables" via
Microsoft's OleDB libraries and classes. (Advise: don't bother.) This
idea of yours is much more flexible. In theory, there could be a server
framework that, with a few well-defined callbacks, could make any data
store acccessible via TDS. Many possibilities fall out of that.
More information about the FreeTDS