From: Lennon Day-Reynolds <rcoder@...>
Date: 2004-07-29T07:38:47+09:00
Subject: Re: Stupid ODBC!

That's what I was afraid of. Maybe I can use the 'info' method on the
database handle immediately after connecting to get the connect log
strings, and just grep for known driver types to figure out what to
use to replace rowid.

It also means that the ODBC code is going to have to reproduce or call
a whole bunch of existing adapter-specific stuff, though, which
ideally would mean refactoring at least those methods out into some
sort of database utilities module.

The problem is that it appears that SQL Server (and most like the Jet
engine, too) has *no* way to get said information -- if you want a
'rowid', it has to be in your table schema.

Looks like this will be a bit more than a few hunded lines of code in
one class, and so won't likely be usable soon enough for the project
I'm working on right now. Time to brush up on my ADO, I guess!

Lennon

On Thu, 29 Jul 2004 07:18:48 +0900, Nathaniel Talbott
<nathaniel@talbott.ws> wrote:
> 
> 
> On Jul 28, 2004, at 18:04, Lennon Day-Reynolds wrote:
> 
> > So, in response to David's call for contributions of adapters for
> > Active Record, I've been working on an ODBC adapter. Unfortunately,
> > I've come up against a limitation of the ODBC spec when compared to
> > most native database APIs there appears to be no standard way of
> > getting an identifier for the last row inserted. Since one of the
> > primary methods that an Active Record database adapter must implement
> > ('insert') is expected to return this value, I appear to be stuck for
> > the moment.
> >
> > Does anyone have a general solution for this they've used (or seen
> > described/mentioned) elsewhere? Alternately, might there be a
> > workaround to remove this requirement from the adapter interface in
> > Active Record, w/o breaking the rest of the system? (David, that one's
> > all yours to answer, most likely.)
> 
> As far as I know, getting the last row id is specific to the underlying
> database, so you'll probably have to allow users of your ODBC adapter
> to specify a bit of code for retrieving it. Of course, you could
> provide a collection of the most common ones, too.
> 
> Does ODBC have a way to get the type of database it's sitting on? If it
> does, you could even auto-select the right method for the user (or warn
> them if there isn't one for their database).
> 
> HTH,
> 
> Nathaniel
> Terralien, Inc.
> 
> <:((><
> 
>