> Roman Rokytskyy escreveu:
>>>> Don't you need to update main database file to put a "label" that
>>>> database is in "nbak"-like mode? I guess some more functionality is
>>>> needed...
>>>>
>>> Yes, but the database may be burned to CD already locked. The
>>> application will need to be installed on a fixed path.
>>>
>>> What I don't know is if the engine will open the file on the CD
>>> (read-only) and the delta in read-write mode.
>>>
>>
>> So, in fact we have two requirements:
>>
>> a) allow opening delta-file in read-write mode even if main database is
>> opened in read-only mode;
>>
> Better thing:
> - if main file can't be opened, try open in read-only mode.
> - if open succeed and the file is locked, continue
>
>> b) allow specifying a custom path for deltas in the firebird.conf file.

In DPB seems more useful - application knows available r\w directory
on target system while firebird.conf creator can't predict it.

>> The only drawback of this scheme is that there are no chances of
>> nbak-ing the delta with nbak. But I think this is quite acceptable for
>> this use case, since we're talking about embedded use where main
>> database is bigger than delta.
>>
> I know some very interesting features that could be done (easily) with
> NBAK. The problem is the understandable NBAK code. :-)
>
> For example:
> - replication
> - flash back queries
> - faster incremental backups
> - database "branches" - database with various independent delta files -
> very useful for group of people developing/testing on one copy of big
> production database without interfering with others

- validation of database integrity without requirement of single attachment

Regards,
Vlad