Hi,

> However, things like RDB$DB_KEY are database-specific, aren't they?

They are. But I suspect that every vendor has some equivalent.

> 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

http://www.cvalde.net/document/mysteriousDbKeyI.htm

> (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).

System tables are described in Language Reference document.

> Anyway, is there somewhere that describes RDB$DB_KEY, etc.?

That's the only RDB$ field outside the system tables that I know.

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

You can set it: see Statement.setCursorName(...). Note, also you have
to use SELECT ... WHERE ... FOR UPDATE OF <cursor_name> statement.

> Excellent, that was what I thought I may have to do - get the
> metadatafrom the ResultSet and automatically generate an update
> (prepared) statement. This can hopefully keep this independent of
> the underlying database :-)

Yup.

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

There's a bigger set of joins that can be updatable, but you can limit
yourself to this subset.

> Fantastic... is there any planned schedule for this (or development
> 'roadmap')?

This will not happen very soon.

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

Admin team is working on the Firebird roadmap, but current document
does not contain dates. There will be 1.5.1 release pretty soon, then
we plan one more release with many features from HEAD (most likely we
start working on this release this year), then goes Vulcan merge. But
again, dates are not fixed, feature sets are not fixed and version
numbers are not fixed. This is currently under discussion.

Roman