We have:

BACKUP DATABASE "dbname" AS "filename" TO "storename"

- Tables and data, but no INFORMATION or CONFIGURATION parts

BACKUP DATABASE "dbname" AS "filename" TO "storename" INCLUDE CATALOG

- includes all table structures

BACKUP DATABASE "dbname" AS "filename" TO "storename" INCLUDE CATALOG ONLY

- only  INFORMATION or CONFIGURATION (I think).

--

If you call RESTORE DATABASE from a backup-file created "CATALOG ONLY" you get the catalog ... but you don't get the empty tables.

For me it would be really useful to be able to BACKUP the whole empty database without including data from a simple SQLStatement such as:

BACKUP DATABASE "dbname" AS "filename" TO "storename" INCLUDE EMPTY TABLES

Such a statement makes it easy to create a "new start" for an application, it also is very useful to use when generating an UPDATE script using EDBManagers automated "Migrate" feature.

--

There may well be another way to do this which is just as easy ... in which case I'd be grateful to hear it!

Adam


I'm not 100% sure what you're trying to achieve here. However, this statement "but you don't get the empty tables" makes me wonder if you are misunderstanding one of the features of ElevateDB.

I'm assuming that you're referring to the table files (the EDB... files). If so don't worry. Whilst there's a little bit more than just the table data in the files empty ones don't count. What will happen is that as soon as an attempt is made to open the table through ElevateDB for whatever reason the table files will be created.

Roy Lambert [Team Elevate]

My requirement is a bit specific.

I have distributed versions of databases. I quite regularly use EDBManager to generate the UPDATE script to bring my field version of the database into line with my development version.

Its a terrific hidden feature of EDBManager in the "Reverse Engineer Database" form you can open when you have a database selected.

Many of my databases are gigs large even when in backup.

I had hoped the use the Catalog only backup file to generate the UPDATE script ... but it doesn't.

I can write a function to iterate the TABLES table and open all the tables to make them available to the Reverse Engineer feature I guess. That wouldn't be too hard.

Adam


So if we revisit your original suggestion what you're really asking for is:

UPDATE STRUCTURE database USING BACKUP CATALOG bkup

Personally I don't like the concept but then most of the restructurings to my databases couldn't be handled in that way anyway.

Roy Lambert [Team Elevate]

Adam,

<< I had hoped the use the Catalog only backup file to generate the UPDATE
script ... but it doesn't. >>

I'm still not sure what you're doing here.  I think I understand what you're
*trying* to do, but not how you're doing it.

If you're trying to upgrade an existing database to a newer version, you
should just ship over the SQL upgrade script and execute it.  You don't need
a database backup at all.

--
Tim Young
Elevate Software
www.elevatesoft.com

>>If you're trying to upgrade an existing database to a newer version, you
>>should just ship over the SQL upgrade script and execute it.  You don't need
>>a database backup at all.

I use EDBMgr to generate the update script, from the "newer" database. The problem is just that I like to keep a copy of the database in different 'versions' for comparison, so I can see what has changed.

If I backup the database without data I get a backup file, but EDBMgr can't compare this with a "real" database (I am using Reverse engineer -> Upgrade then comparing the existing DB to the empty version to generate the upgrade script) as if there are no table objects EDBMgr's upgrade option generates an empty script.

I guess I am just asking for slightly more ability to fine tune the BACKUP DATABASE command, so you can be a bit more picky about what gets backed up.

Extending this a bit it would be nice to be able to have WITH VIEWS, PROCEDURES, FUNCTIONS / WITHOUT VIEWS ... or similar.

I would like to have a NO DATA WITH TABLES option ...

... sorry to be a fussy user, but I am using EDBMgr & EDB a lot now & would love to see its functionality extended!

Adam,

<< I guess I am just asking for slightly more ability to fine tune the
BACKUP DATABASE command, so you can be a bit more picky about what gets
backed up. >>

I'll have to think about any potential issues with this, but it's not too
difficult to do what you're asking.

--
Tim Young
Elevate Software
www.elevatesoft.com