The SQL Dialect determines the interpretation of several constructs
"String" vs "Identifier"
DATE (meaning timestamp) vs DATE (meaning date only)
The result of numeric functions (Is 1/3 == 0 or 1/3 == 0.3333333333...)
Availability of DATE only datatype, TIME datatype, ?64 bit int?

I agree with Sean -- the new ODBC driver should keep in conformance
with dialect 3 only.

Should it become necessary to use older dialects, a property of the driver
as Jim proposes sounds find (with Dialect 3 being default)

Dave

-----Original Message-----
From: Leyne, Sean [mailto:InterbaseArchitecture@...]
Sent: Tuesday, May 23, 2000 1:20 PM
To: 'IB-Architect@egroups.com'
Subject: RE: [IB-Architect] SQL Dialects and ODBC



Jim,

-----Original Message-----
From: Jim Starkey [mailto:jas@...]
Sent: Tuesday, May 23, 2000 3:48 PM
To: IB-Architect@egroups.com
Subject: [IB-Architect] SQL Dialects and ODBC

InterBase SQL, now old enough to drive in 45 states, originally
supported both single and double quoted literal strings. The
current SQL standard provides for single quoted literal strings
and double quoted identifier strings. This is pain, but has
to be dealt with.


What's the pain?


V6 InterBase differentiates between the two by a "sql dialect"
identifier passed in on the isc_dsql_prepare and isc_execute_immediate
calls.

The question of the hour is how the ODBC driver should interprete
SQL strings since a) existing programs use double quotes for
literals and b) new program will use double quotes for identifiers.


Personally, I don't think that the ODBC driver should not care about
existing programs (which presumably don't use ODBC for connections).
There comes a point in time when systems need to be updated to conform
to the "latest thinking", your new driver seems to be case and point.
The use of the ODBC driver should conform to the appropriate standards.
ODBC is/was intended to provide a seamless access to datasources,
accordingly, these programs need to use conforming SQL.


There isn't a good way to handle this because in a good world this
wouldn't happen. Please note that BLR was immune to this sort
of problem [sigh].

A candidate solution would be to an attribute to the driver
connect string passed through SQLDriverConnect. It would also
be configurable through the ODBC configuration mechanism,
so a system default could be established.

Does anybody have any better ideas?

Jim Starkey

------------------------------------------------------------------------
Click here for savings: beMANY!
http://click.egroups.com/1/4115/4/_/830676/_/959111443/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com



------------------------------------------------------------------------
Best friends, most artistic, class clown Find 'em here:
http://click.egroups.com/1/4054/4/_/830676/_/959113222/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com