[freetds] Status of support for Time type

Frediano Ziglio freddy77 at gmail.com
Thu May 2 01:34:40 EDT 2013

2013/5/1 James K. Lowden <jklowden at freetds.org>

> On Tue, 30 Apr 2013 20:05:00 +0100
> Frediano Ziglio <freddy77 at gmail.com> wrote:
> > Problem here is also that you are using dblib which is not supposed
> > to be extended!
> >
> > As Microsoft decided to not update it we should find a way to
> > compatibly extend dblib in order to put/get time/date!
> It is easily done, if one has the time.  What needs extending other
> than dbbind() and bcp_bind()?
> ISTM dbbind() should support binding a server's DATE or TIME to
> DBDATETIME or DBDATETIM4, subject to domain constraints.  Although
> there are new types, most databases still keep data per the
> Gregorian calendar, and most days are still 24 hours.  Mapping the new
> date & time column types to the existing db-lib structures would allow
> existing programs to use the new column types merely by relinking to a
> newer FreeTDS.
> For completeness -- to support new applications using the extended date
> range -- dbbind() would need new structs and new bindings.
> For structures I would use those already defined for ODBC.  Microsoft
> defines these, but I don't see support for them in tds_convert()?
No, libTDS does not support ODBC types. Well... there should be perhaps a
way to support more types but actually tds_convert support only "libTDS"

> struct tagDATE_STRUCT {
>    SQLSMALLINT year;
>    SQLUSMALLINT month;
> struct tagTIME_STRUCT {
>    SQLUSMALLINT minute;
>    SQLUSMALLINT second;
> For binding, dbbind() defines SMALLDATETIBIND and DATETIMEBIND. I would
> suggest adding DATEBIND and TIMEBIND.
If program bind these type is not a big issue. However if program want to
read the type and FreeTDS start returning type that client does not support
client cannot handle them so there should be a way for the client to tell
"I support this type, feel free to return it".

> Those are needed only for binary bindings, and only if we adopt new
> structs.
> Just a small matter of programming.
Of course, but when ABI changes are required some design in advance is not
bad :)


> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds

More information about the FreeTDS mailing list