Skip to Content.
Sympa Menu

freetds - Re: ODBC in CVS head: SQL_DATETIME?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Steve Langasek <vorlon AT netexpress.net>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Cc: iODBC Maintainer <iodbc AT openlinksw.com>
  • Subject: Re: ODBC in CVS head: SQL_DATETIME?
  • Date: Sat, 24 Nov 2001 16:44:55 -0600

Patrick,

On Sat, Nov 24, 2001 at 09:59:49PM +0100, iODBC Maintainer wrote:

> > As of revision 1.2 of src/odbc/odbc.c (which includes a changelog entry
> > reading 'fixed SQL_DATE things in ODBC'), this file contains a reference
> > to a SQL_DATETIME constant. However, I've been unable to locate this
> > macro in either the iODBC headers or the unixodbc 2.0.8 headers, and its
> > abence naturally causes compilation of the ODBC driver to fail. I have
> > found one reference to SQL_DATETIME in the unixodbc 2.0.11 headers, so
> > compilation against unixodbc is possible. But how should this be
> > handled so that people who only have iODBC installed can still compile
> > this driver?

> The current version of iODBC does have this constant. You can download the
> latest iODBC version from:

> http://www.iodbc.org/

> This constant was introduced in ODBC V3 API specification and has been
> part of the iODBC source for a long time now. I have successfully compiled
> the FreeTDS ODBC driver with iODBC.

Thanks for the insight. I do most of my development on Debian systems,
where the current iODBC package is version 2.50.3; and at least for
Debian packaging, this is the target version of iODBC I have to be able
to build freetds against for the time being. As for the unixodbc
package in Debian, I have no one but myself to blame, as I'm the
maintainer of that package -- but I'm currently fighting with some C++
issues on the alpha (namely, a buggy compiler) that are preventing me
from getting an update out the door. :/

BTW, I notice that you mention "x86, Itanium, Alpha, Mips, and StrongArm"
Linux ports of iODBC on your website. Just in case you're interested:

vorlon@auric:~$ madison libiodbc2
libiodbc2 | 2.50.3-1 | stable | source, alpha, arm, i386, m68k,
powerpc, sparc
libiodbc2 | 2.50.3-4 | testing | source, alpha, arm, hppa, i386,
ia64, m68k, mips, mipsel, powerpc, s390, sparc
libiodbc2 | 2.50.3-4 | unstable | source, alpha, arm, hppa,
hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sh, sparc

So, you can add the PA-RISC, m68k, PowerPC, S390, SuperHitachi, and
Sparc processors to the list if you'd like. :)

> > I see SQL_DATE used elsewhere in the source, and SQL_DATE and
> > SQL_DATETIME both have the same value in unixodbc 2.0.11. Is it
> > acceptable to s/SQL_DATETIME/SQL_DATE/ on the source and call it good,
> > or is this just a coincidence?

> As your driver is currently written against the ODBC 2.0 specification, i
> recommend you use the SQL_DATE constant. You may also want to compile with
> -DODBCVER=0x0200 to make sure you do not use ODBC 3 constants by mistake.

This sounds reasonable to me. Unless someone objects, I'll back the
SQL_DATETIME reference out of CVS and edit src/odbc/Makefile.am to explicitly
reference ODBCVER=0x0200; I'm guessing that it will be some time before
an ODBC 3.0 driver is an explicit goal.

Cheers,
Steve Langasek
postmodern programmer

Attachment: pgppnw9Ko1wfd.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page