>>>> Database header page information:
>>>> Flags 0
>>>> Checksum 12345
>>>> Generation 84490
>>>> Page size 4096
>>>> ODS version 10.1
>>>> Oldest transaction 81692
>>>> Oldest active 84481
>>>> Oldest snapshot 84481
>>>> Next transaction 84482
>>>> Bumped transaction 1
>>>> Sequence number 0
>>>> Next attachment ID 0
>>>> Implementation ID 16
>>>> Shadow count 0
>>>> Page buffers 0
>>>> Next header page 0
>>>> Database dialect 3
>>>> Creation date Feb 8, 2008 9:00:35
>>>> Attributes force write, no reserve
>>>>
>>> I give in,... what's 'no reserve'
>> No space on data pages is reserved for back record version.
>>
>> Usually the no reserve option makes sense for databases which are
>> read-only, e.g. on CD ...
>>
>>
>> --
>> Best Regards,
>> Thomas Steinmaurer
>
> so if it's read only, how is that impacting on the OP's saving or loss of
> data?

Ehm, the usage of no reserve doesn't imply that it is a read-only
database. You can have a read-write database with the no reserve option,
which is not a good idea performance wise.

I don't know if data loss is related to using no reserve. I doubt.

Perhaps the transaction didn't commit. Or data loss means: "another user
doesn't see my changes ...." Or a restore is run with -R switch of gbak.
Who knows. ;-)

--
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com
My blog:
http://blog.upscene.com/thomas/