Skip to Content.
Sympa Menu

freetds - RE: [freetds] Problem with datetime from a MS SQL Server

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: ZIGLIO Frediano <Frediano.Ziglio AT vodafoneomnitel.it>
  • To: "'freetds AT lists.ibiblio.org'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Problem with datetime from a MS SQL Server
  • Date: Tue, 11 Feb 2003 10:54:17 +0100

>
> On Mon, 10 Feb 2003 22:23:41 -0600, Steve Langasek
> <vorlon AT netexpress.net>
> wrote:
> > On Mon, Feb 10, 2003 at 09:22:32PM -0500, James K. Lowden wrote:
> > > > Failing that, it's always possible to double the
> structure. <shrug>
> >
> > > This is safest, but would need a different answer for binary
> > > compatibility.
> >
> > Because DBDATEREC is a public structure, any size changes are also a
> > binary-incompatible change. If two separate month fields are to be
> > included (a minimum requirement if we're providing both sets of
> > semantics), an ABI change is unavoidable.
>
> Oh, we're on different wavelengths here. I had in mind a
> future configure
> switch:
>
> --with-abi= [sybase|microsoft|freetds] #default freetds
>
> superseding --with-sybase-compat.
>
> We've already taken baby steps down that road. I don't know where it
> ends.
>

Arghh...

We have two compatibily now. MS and Sybase. MS is widely accepted on windows
while Sybase on unices. So why don't we provide default MS binary
compatibily for windows and Sybase one for unices??

A method to provide both behaviour is to use something called in C++ "name
mangling".
For example provide (under unices) two functions: dbdatecrack and
dbdatecrack_ms. Defining MSDBLIB in source file activate a #define
dbdatecrack dbdatecrack_ms so programs compiled in such way use Microsoft
behaviour while other use Sybase behaviour...
If anybody want to port windows program and use also Sybase compatibility
this seem a good solution...
I don't think there is much difference between ms and sybase...

freddy77

=================================
"STRICTLY PERSONAL AND CONFIDENTIAL

This message may contain confidential and proprietary material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please contact
the sender and delete all copies.
The contents of this message that do not relate to the official business of
our company shall be understood as neither given nor endorsed by it."

=================================




Archive powered by MHonArc 2.6.24.

Top of Page