Skip to Content.
Sympa Menu

freetds - Re: [freetds] db-lib: support for new MS SQL 2008 data types - part 3

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: LacaK <lacak AT zoznam.sk>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] db-lib: support for new MS SQL 2008 data types - part 3
  • Date: Thu, 17 Apr 2014 07:26:14 +0200

Frediano Ziglio wrote / napĂ­sal(a):
2014-04-16 12:44 GMT+01:00 LacaK <lacak AT zoznam.sk>:
Hi again,
Now I am personally happy with patched db-lib in regards of support new DATE
- TIME data types.

Great! Yesterday I discovered a problem with BCP adding some tests for
these new types, still to fix.


May be, I have never used bcp_* functions ;-)


But there are still missing some parts, which may be interesting to somebody
else.
I meant dbbind() family of API with corresponding *BIND constants and binary
structure used to store this types.

How to handle binding of new date, time types ?

- introduce new DBDATETIMEALLBIND (or DBDATETIME2BIND) constant in sybdb.h ?

could work

- introduce new DBDATETIMEALL struct (==TDS_DATETIMEALL struct) in sybdb.h
?

Mmm... well... could be or not. Microsoft for ODBC defined quite
different structures (one more similar to DBDATEREC). TDS_DATETIMEALL
is neither from TDS protocol neither intended to be presented to
clients. It's a mix of TDS protocols, numeric, old dates (values are
the same as dtdays).

On the other end I could understand that
providing dbdata different from libTDS is far from easy.

Exactlly!
It is main reason why I am still speaking about TDS_DATETIMEALL ;-)
And as I already wrote because of similarity of:
SQL Server libTDS DB-Lib
------------------------------------------------------------
datetime -> TDS_DATETIME == DBDATETIME
smalldatetime ->TDS_DATETIME4 == DBDATETIME4

I will be happy also with SQL_TIMESTAMP_STRUCT (or other struct), to be public structure for these new date time data types, but IMO then this struct must be used also internaly by libTDS to store values in record buffer. Because if libTDS will continue use TDS_DATETIMEALL then it will significantly complicate things on db-lib level. (as there will be required conversion in many places)

- add support to copy_data_to_host_var() function in dblib.c ?


Ehmm... what do you mean?

In db-lib is function copy_data_to_host_var() which is called when next record is fetched to store fetched column values to local program variables for bind columns.
If you look at this function there are performed type conversions very simlar to dbconvert().
So we must add there also cases for SYBMSDATE...SYBMSDATETIMEOFFSET (like we did for dbconvert())

If you give me direction I can prepare patch ...
(if it is good idea add support for BINDing ?)

Not good, excellent! And much easier as you don't have to store a
buffer but you can provide what do you want to the client.
Yes

So only think we must agree on is : what "struct" we will use for new date time data types ?
If it will be TDS_DATETIMEALL then it makes things easy and compact.
If it must be something else then my proposal is use same struct in libTDS instead of TDS_DATETIMEALL.

Thanks
-Laco.





Archive powered by MHonArc 2.6.24.

Top of Page