When restoring a table from backup, does it matter if the structure of the table in the backup is different than the table to be restored ?

The situation is I have a database server here for dev, and I backup the db here and then ftp it to AWS and restore it there. Now though, the local table is different (new fields) than the AWS copy. Does DBISAM just copy all the table files as a file copy or does it do something like a Empty table and then do mass insert. If it's by file, then difference is unimportant, whereas if it does it by insert then it's a problem.

Arthur


I don't know the guts of DBISAM and these days use ElevateDB but here goes.

My understanding is that essentially a DBISAM backup is equivalent to a file copy with compression.

DBISAM holds the metadata in the file headers not in a separate catalog as ElevateDB does. Therefore, when you backup you copy the table structure with the files, and when you restore the table structure is what is in the files being restored. Essentially a file copy and overwrite operation.

Roy Lambert

Arthur,

<< When restoring a table from backup, does it matter if the structure of the table in the backup is different than the table to be restored ? >>

As Roy indicates, the structure of a table is stored in the table header itself, so the result of restoring such a table is that the existing table structure will be replaced with that of the restored table.

The backup/restore in DBISAM uses a raw copy operation (with compression), so it's equivalent to an OS copy operation from the outside (minus some details like database locking, etc. to prevent restoration while a table is in use, etc.

Tim Young
Elevate Software
www.elevatesoft.com

So, then, if you change your database structure, how do you handle restorations? External conversion utility?

I ask because I'm in said boat, where I've changed the structure of some of my tables (not destructively, but changed nonetheless), and now my customers' backup files would seem to be an issue.

The backup/restore functionality feels like it should be separate from the main app, since the only solution I can see currently is using an old version of the program on old backups, restoring them, then using the newer version of the program to upgrade them to the newer structure.

On 10/21/2018 8:37 PM, Blake wrote:
> So, then, if you change your database structure, how do you handle restorations? External conversion utility?

Restore will restore table to whatever structure was when backup was
taken. You need a to apply your updates again/

> I ask because I'm in said boat, where I've changed the structure of some of my tables (not destructively, but changed nonetheless), and now my customers' backup files would seem to be an issue.

Should not affect the backup - have you run repair on them to make sure
they don't have issues to being with.

> The backup/restore functionality feels like it should be separate from the main app, since the only solution I can see currently is using an old version of the program on old backups, restoring them, then using the newer version of the program to upgrade them to the newer structure.

Depends on your usage scenario. In our case we put it in to our software
(since it needs to do this during app upgrades anyway). It has
per-table/per-version upgrade capability so once restore is done one
starts the app and it will upgrade to current structure.

Raul

Raul,

Thanks for the info. I think my problem is actually related the restore problem I put up in the other thread. I mistakenly thought it was a structural thing, but if I understand you correctly, the restore should work--but then I might have trouble if my code expects fields that didn't exist in the old backup.

On 10/23/2018 12:28 AM, Blake wrote:
> Thanks for the info. I think my problem is actually related the restore problem I put up in the other thread. I mistakenly thought it was a structural thing, but if I understand you correctly, the restore should work--but then I might have trouble if my code expects fields that didn't exist in the old backup.

Yes you app needs to detect and handle )potentially) older table.

Each table has version info fields (major and minor) that you control so
you can use those to "detect" for example it's an older table in the app
and trigger update logic - and that same upgrade logic would update the
version when it changes the table.

Raul