Re: Status of support for Time type

2013/5/1 James K. Lowden <[email protected]>

> On Tue, 30 Apr 2013 20:05:00 +0100
> Frediano Ziglio <[email protected]> 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"
types.


> struct tagDATE_STRUCT {
>    SQLSMALLINT year;
>    SQLUSMALLINT month;
>    SQLUSMALLINT day;
> } DATE_STRUCT;
>
> struct tagTIME_STRUCT {
>    SQLUSMALLINT hour;
>    SQLUSMALLINT minute;
>    SQLUSMALLINT second;
> } TIME_STRUCT
>
> 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 :)

Frediano



> --jkl
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
>