Re: dbcoltype char vs. datetimeoffset

On Mon, 23 Sep 2013 07:20:29 +0000
Chris Kings-Lynne <[email protected]> wrote:

> Ah. I see that version 8.0 and 7.2 are mapped to 7.2 in PHP dblib.  I
> imagine that's due to the MS vs. Sybase version naming confusion?

Upon a time, Microsoft did not document the TDS protocol and you could
scarcely find mention of it on their website.  I think FreeTDS called
it TDS 7.0 because at the time SQL Server was at version 7.0.  When SQL
Server 2000 came out, we could hardly call it TDS 2000, so it became
TDS 8.0, why not?  

After the EU insisted on documentation for proprietary protocols,
Microsoft retrodocumented TDS, providing the 7.0, 7.1, etc. names.
FreeTDS latterly adopted them and confused pretty much everyone who
wasn't reading the fine print.  ;-)

> So basically I have to fix FreeTDS to recognise the new type...any
> hints on where to start?

There isn't that much to do, and if you're willing to undertake it I'm
happy to answer any questions on-list or off.  You'll find some
of my earlier commentary and ideas in the email archive from the past
year.  

libtds already supports TDS 7.3, which is when the new date types were
defined.  Things to keep distinct in your mind as you're looking through
the code:

1.  Datatypes defined on the server have designated tokens -- a small
integer -- in the protocol.  That's what it means to say a varchar is
type 47.  Symbolic constants for these in db-lib have the form SYBxxx.
They are sent by the server as metadata for arriving columns or
output parameters, and are used by db-lib (rather casually) to describe
program variables in e.g. dbrpcparam and bcp_bind.  

2.  C datatypes have symbolic constants of the form DBxxx.  For
example, DBINT is defined as a C int on most machines.  

3.  db-lib has another symbolic constant to describe the format to
be used for the bound buffer.  These all have names that end in "BIND",
as in NTBSTRINGBIND.  I doubt you'll have to extend that.  

4.  Conversions are all done in src/tds/convert.c. It's a little
confusing at first, but it's reasonable and regular, like the people
who wrote it.  

5.  ODBC already has most of the bits you need because it already
supports these types (in the git repository master version).  Some may
have to be moved down to libtds to be shared between client libraries.
Others will have to be copied into db-lib and renamed in the db-lib
style.  Anything in the bcp library will be brand new because ODBC
doesn't support bcp.  

There's a little two-liner in there somewhere to prevent db-lib from
connecting with TDS 7.3.  You'll want to remove that.  

For navigating the code, cscope is your friend.  

I recommend extending a unit test during development, because a small,
simple program is quicker to re-run and debug.  

You don't have to do everything; it's fine to do the parts that meet
your immediate needs.  A complete job, for the record, would be

1.  string binding for dbbind, dbrpcbind, and bcp_bind
2.  tokens for dbcoltype and dbcolinfo
3.  typename strings for dbprtype
4.  binary structs for dbbind, dbdata, dbrpcbind, and bcp_bind
5.  an extension for dbdatecrack
6.  documentation
7.  accolades

HTH.  

--jkl