Subject | Re: [firebird-support] Firebird/ASA/Clarion |
---|---|
Author | Jonathan Neve |
Post date | 2004-04-02T12:14:13Z |
Steffen Heil wrote:
automatic. But currently, there's nothing even to restore from! All you
can do is fall back on the last backup. This, on the other hand, would
be a sort of incremental backup. Perhaps the best thing would be a
syntax similar to the following :
CREATE BACKUP (this isn't the right word, we would have to find a new
one) <NAME> [PARAMS];
SELECT <COLS> FROM <BACKUP_NAME>(<TIMESTAMP>).<TABLE_NAME>;
INSERT INTO <BACKUP_NAME>(<TIMESTAMP>).<TABLE_NAME> (<COLS>) VALUES
(<VALUES>);
ETC...
This sort of thing would be good. It's true that if we make things
completely automatic, it will be unasable. But if we simply make the
tables the backup contains accessible, based on a certain timestamp,
then after that, it could be manipulated as though it were an ordinary
part of the database, allowing you to be as flexible as you need to be.
This could use the same syntax as that which will be used if/when it
becomes possible to access an external database simultaneously (I think
I heard talk of this perhaps getting implemented one day). The backup
could be treated just as though it were an external database, except
that it would be read-only, and there would be no triggers nor procedures...
Jonathan Neve.
[Non-text portions of this message have been removed]
>HiCertainly. I'm not suggesting that the restore process be entirely
>
>
>>Or else, what might be good would be something like a shadow file, in
>>
>>
>which, all obselete record versions are dumped, as and when they become
>obselete. Then, there could be a simple API (or perhaps an SQL extention)
>that could be used for loading old record versions back into the DB, and
>also for purging out old versions periodically...
>
>This seems even theoretically impossible to me: What happens, when you have
>a trigger, creating a record in one table when deleteing a record in
>another?
>If you restore that record "from outside", will you also remove the record
>created by the trigger? What if this invokes another trigger......
>
>So this is not implementable as a generall approc
>h.
>
>
automatic. But currently, there's nothing even to restore from! All you
can do is fall back on the last backup. This, on the other hand, would
be a sort of incremental backup. Perhaps the best thing would be a
syntax similar to the following :
CREATE BACKUP (this isn't the right word, we would have to find a new
one) <NAME> [PARAMS];
SELECT <COLS> FROM <BACKUP_NAME>(<TIMESTAMP>).<TABLE_NAME>;
INSERT INTO <BACKUP_NAME>(<TIMESTAMP>).<TABLE_NAME> (<COLS>) VALUES
(<VALUES>);
ETC...
This sort of thing would be good. It's true that if we make things
completely automatic, it will be unasable. But if we simply make the
tables the backup contains accessible, based on a certain timestamp,
then after that, it could be manipulated as though it were an ordinary
part of the database, allowing you to be as flexible as you need to be.
This could use the same syntax as that which will be used if/when it
becomes possible to access an external database simultaneously (I think
I heard talk of this perhaps getting implemented one day). The backup
could be treated just as though it were an external database, except
that it would be read-only, and there would be no triggers nor procedures...
Jonathan Neve.
[Non-text portions of this message have been removed]