FreeTDS Development Group

["Mike C." <mcbp223 AT yahoo.com>]

> From: Lowden, James K LowdenJK at bernstein.com
> Sent: Sat Mar 27 11:16:15 EST 2004

> If you're writing a new TDS server and would like to add this flexibility
> to FreeTDS, I don't have any objection.  It looks like a fairly small
> modification, and I agree the TDS specification allows it.  Is that how
> you generated the traces you posted?
I'm flirting with the idea of writing some ODS layer or gateway, and see
what clients I can talk to.
The traces are coming from some tests done this way.

> If you've found a proprietary implementation that uses a txtptr size of
> something other than 16, then clearly we need to support it.  It would be
> helpful, though, to have a way to test it....
No, that's not the case, and I don't know of any TDS servers other than MS
and Sybase actually.

> > I was wondering why do you do the switch based on size instead of data
> > type?
> I think I don't understand the question.  We read a byte, that byte says
> the txtptr is 16 bytes, so we read them.  What data type?  Unless you mean
> the column type?
Yes why do the switch on column_varint_size instead of column_type, just
curious.

> > I can send you my source code for the tests I'm doing, but it's in C++
> > on VC6 so far.
> It might be interesting.  I'm curious about what you're up to, if you care
> to discuss it.
I have uploaded the code
http://www.geocities.com/mcbp223/tests.odsrv.2004-03-29.zip
It is in C++ on VC6/7 and right now compiles for a dir list, with
exec TDSTESTDIR:c:\some_files\*.txt from QA. It's using variable arbitrary
size for textptr in this test.

I am interested by any ideas for opening up the server end-point of TDS as
you guys did with the client side.

Mike