Are there any plans to add support for mapping SQL_SS_TIMESTAMPOFFSET to/from TIMESTAMP WITH TIME ZONE in the SQL Anywhere ODBC drivers? The MobiLink server .NET API reference says that they "can be used only against Microsoft SQL Server and Oracle databases". If not, could encouragement from users spark interest? Is there a technical issue that flat out prevents it? Is it (fingers crossed) actually supported, but just not documented? After all, the documentation (Ways to send dates and times to the database) says "The date and time of day with a time zone offset can be sent to the database as a string only.", but I've found that Entity Framework, at least, happily maps TIMESTAMP WITH TIME ZONE to System.DateTimeOffset. |
Yes there is - maybe not "prevent" it from ever happening, but certainly "makes it more difficult to implement". In general, our ODBC driver targets ODBC version 3.5, due to general compatibility concerns with third-party ODBC driver managers on UNIX operating systems (e.g. unixODBC, and iODBC). From: http://msdn.microsoft.com/en-us/library/bb677267.aspx
and: http://msdn.microsoft.com/en-us/library/windows/desktop/ms714822%28v=vs.85%29.aspx
So we would have to re-target our ODBC compliance level for our ODBC driver and then third-party ODBC managers have to implement ODBC 3.8, in order to make such a change fully work.
This is a string to native type mapping that happens inside the provider. It's still returned as a string back from the database underneath the covers. Is there a specific issue are you encountering due to this issue? Most of our customers are able to use the TIMESTAMP WITH TIME ZONE type directly as a string. 2
Thank you for the excellent, detailed, informative answer. As part of upgrading from SA 11.0.1 to SA 16, we're planning to convert some of our TIMESTAMPs to TIMESTAMP WITH TIME ZONEs. Among other things, I'm looking into how that affects our C++ ODBC code, which currently uses TIMESTAMP_STRUCT. With your guidance, I'll now plan for the changed fields to bind strings. You've saved me a lot of research and testing. THANK YOU! (By the way, I'm glad that you deal with the internal intricacies of ODBC drivers, so that we don't have to.)
(30 May '13, 14:01)
Dan Konigsbach
Replies hidden
Comment Text Removed
1
"I'm glad that you deal with the internal intricacies of ODBC drivers, so that we don't have to." - amen!
(30 May '13, 16:03)
Breck Carter
|