Couldn't you use the system tables to pull the pk for the table?

I know the .net driver does this with it's command builder.


Christoph

> -----Original Message-----
> From: phil_hhn [mailto:time_lord@...]
> Sent: Wednesday, 23 June 2004 8:28 AM
> To: Firebird-Java@yahoogroups.com
> Subject: [Firebird-Java] Re: Updateable ResultSets - any progress?
>
>
> --- In Firebird-Java@yahoogroups.com, "Roman Rokytskyy"
> <rrokytskyy@a...> wrote:
> > > I have a database in front of me with 1 or 2 large tables, and
> > > typically a row from one of these is to be displayed (say
> 50 fields),
> > > then the user can edit *any* field. An updateable
> ResultSet would be
> > > nice...
> >
> > As I probably already described, main problem in implementing this
> > feature is need to rewrite the SQL submitted by user to add
> necessary
> > RDB$DB_KEY field(s). Having done this you can always submit
> an update
> >
> > UPDATE tableName
> > SET someField = ?
> > WHERE RDB$DB_KEY = ?
> First, thanks for the detailed reply, there are some good suggestions
> here :-)
> However, things like RDB$DB_KEY are database-specific, aren't they?
> Unfortunately we are targeting more than 1 database (so we want to
> keep our code 'plain vanilla' if possible). Infact I didn't start the
> project with Firebird, but 'rediscovered' it ;-)
> I've had a look around for info on RDB$DB_KEY and haven't had much
> luck other than some examples of its use. I'd like to know more about
> that (and other RDB$ fields). I know there are other system tables
> because I saw them while retrieving db metadata (for a separate
> graphical migration tool I wrote that displays the db structure).
> Anyway, is there somewhere that describes RDB$DB_KEY, etc.?
>
> > Until then you have following options:
> >
> > a) if you do not need scrolling (only forward navigation), you can
> > always use "UPDATE ... WHERE CURRENT OF <cursor name>".
> How does this relate to the ResultSet - can I retrieve a cursor name
> for it?
>
> > b) if you have some time, you can implement these methods that will
> > only work if user submits an SQL containing RDB$DB_KEY. It
> should not
> > be a complex task.
> Well you've lost me already ;-)
>
> > c) code updates into your application. You can create pretty generic
> > solution by introducing an "update object" class that
> contains name of
> > the table, value of the RDB$DB_KEY or, even better, your
> primary key.
> > Then in your application, when field is changed, you have to do a
> > pretty simple thing:
> Excellent, that was what I thought I may have to do - get the metadata
> from the ResultSet and automatically generate an update (prepared)
> statement. This can hopefully keep this independent of the underlying
> database :-)
>
> > This code is pretty generic and will work even if you
> change names of
> > your columns. It requires:
> >
> > a) your result set has only one table (if more than one
> table is used
> > you have to add some logic to deal with PKs)
> Cool, that's pretty standard for updateable cursors
>
> > > Anyway, has there been any interest in implementing updateable
> > > ResultSets?
> >
> > On Fulda conference I had a discussion with Nickolay Samofatov, core
> > engine developer. We agreed that there will be new Firebird API call
> > that will return RDB$DB_KEY field(s) without SQL rewriting.
> When this
> > feature is available, we will implement updatable result sets.
> Fantastic... is there any planned schedule for this (or development
> 'roadmap')? I've also seen some mention of Firebird 2.0 - when is that
> planned for and are there any docs describing what the intended new
> features are?
>
> Thanks very much,
> Phil
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> --------------------~-->
> Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
> Now with Pop-Up Blocker. Get it for free!
> http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/saFolB/TM
> --------------------------------------------------------------
> ------~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>