--- 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