#15 Save table system

[Ben Walding]

For copying a table using select into just prior to an update / delete to protect the work you are about to do

Implement this as a separate form with hooks in for automation by the query engine.

Could also do smart tricks where we add a ref and date column and put only the records being affected into the table.

Also may need an automatic uncorruption engine in the event of failure.

[Ben Walding]

Logged In: YES
user_id=61278

In English this time.

When doing an update / delete there is often the danger of
corrupting data which exists in the system. Although one
could say that the user should be more careful, accidents
happen.

Basically to protect us from this situation, we would take
a backup of any data which was going to be affected. This
data would be backed up into the same database that the
query was affecting (probably using SELECT INTO).

Once the data was backed up, the actual update / delete
query would be run. In the event that the user decided
that there update /delete was wrong, the data could be
rolled back from the holding area.

Implementation:
In the query editor, each query generates an entry in the
past query list (on the right hand side). If the query is
an UPDATE / DELETE, the user should be given an option to
backup the data being affected. If they do decide to this,
the editor should transparently execute the appropriate
SELECT INTO and store the name of the table against the
history. The application should ensure that the backup
table is unique. The application shall only copy rows
which could be affected by the subsequent query

When the user decides to quit, all existing backup tables
should be removed (optional).

If the user realises they have made a mistake, they can
right click the query in question. If there is a backup
table for the query in question, the user can select a
rollback function which restores the data (INSERTs /
UPDATEs existing records).