Subject | RE: [Firebird-Architect] NBAK |
---|---|
Author | Slavomir Skopalik |
Post date | 2008-04-11T19:13:45Z |
Hi All,
please keep in your mind that flash back data should be backuped and
restored.
Also if this data will be as a part of main database file this will
simplified administration
(copy one file), because lot of application will use falsh back forever :)).
But if you have this feature I will be very happy, because I'm using this
offen (implemented
by history table)
.
And history row shoudl have this system columns:
version
utc_TimeStamp
Slavek
is a moment in the past.
.
<http://geo.yahoo.com/serv?s=97359714/grpId=464142/grpspId=1705007183/msgId=
10163/stime=1207937287/nc1=4507179/nc2=3848644/nc3=5170407>
[Non-text portions of this message have been removed]
please keep in your mind that flash back data should be backuped and
restored.
Also if this data will be as a part of main database file this will
simplified administration
(copy one file), because lot of application will use falsh back forever :)).
But if you have this feature I will be very happy, because I'm using this
offen (implemented
by history table)
.
And history row shoudl have this system columns:
version
utc_TimeStamp
Slavek
>That implementation may also be possible. With NBAK, each delta locked
>> - flash back queries
>>
>
> Why do I need NBAK here? I always thought that this can be achieved by
> providing a "flash back depth" parameter to garbage collector to prevent
> garbage-collecting those records and providing the "flash back"
> parameter with the query.
>
is a moment in the past.
.
<http://geo.yahoo.com/serv?s=97359714/grpId=464142/grpspId=1705007183/msgId=
10163/stime=1207937287/nc1=4507179/nc2=3848644/nc3=5170407>
[Non-text portions of this message have been removed]