It would be nice if the triggers were copied with the table. It would of course have to rename the triggers from "Triggerx" to "Triggerx_1" or something similar.

The problem would of course be renaming any references to the old table name to new table name in the new trigger. (I doubt if any of my triggers reference the table name.) This can be left up to the user to do. The triggers of the new table would be disabled and is up to the user to make the manual corrections to the code if needed.

BTW, I did discover I can open a new SQL window and drag the old trigger to the SQL window and the create trigger SQL appears, which helps. But I'd like to see it more automatic.

The reason I'd like to see this is I often want to copy a table (back it up) before I start changing its field definitions etc.. If I screw up, I can revert back to the old table definition. Or I can experiment on the new table that was created and if I like the changes, drop the old table and rename the new table to the old table's name when I'm done.

I don't see any easy way of doing this with EDB without backing up the entire database which in my case is over 1.25gb compressed.

Barry

Barry

You can call

BACKUP DATABASE XXX ... TABLES "TableOne"

This will only backup the table you are altering, saving you disk space.

You can then call

RESTORE DATABASE XXX ... TABLES "TableOne"

and only TableOne will be restored.

If you have changed the structure of TableOne in the mean-time the catalog will be out of sync though ... HUM.

You could get round this by saving a CreateTable script for TableOne in its old format, and DROPING it when you revert ...

Barry

>It would be nice if the triggers were copied with the table. It would of course have to rename the triggers from "Triggerx" to "Triggerx_1" or something similar.
>
>The problem would of course be renaming any references to the old table name to new table name in the new trigger. (I doubt if any of my triggers reference the table name.) This can be left up to the user to do. The triggers of the new table would be disabled and is up to the user to make the manual corrections to the code if needed.
>
>BTW, I did discover I can open a new SQL window and drag the old trigger to the SQL window and the create trigger SQL appears, which helps. But I'd like to see it more automatic.
>
>The reason I'd like to see this is I often want to copy a table (back it up) before I start changing its field definitions etc.. If I screw up, I can revert back to the old table definition. Or I can experiment on the new table that was created and if I like the changes, drop the old table and rename the new table to the old table's name when I'm done.
>
>I don't see any easy way of doing this with EDB without backing up the entire database which in my case is over 1.25gb compressed.

It sounds as though you're operating a bit like me. I have a full copy of the live database as my development database and it gets refreshed occasionally. Way back, before Tim relaxed things a bit, I discovered that the version handling in the catalog made it impossible to just copy the tables as I used to be able to do in prehistoric times with DBISAM. My solution was to EXPORT and IMPORT. The advantage to this is that its version agnostic providing headers are included.

What you could do is export your data, zip it if you need to, backup the catalog and then in the event of needing to rollback copy the catalog, and import the data. Its a bit messy but for me export from live, import to development, run a script to change user codes throughout the system from my live login to my development one, and alter peoples email & phone numbers. It takes about 20 minutes over the LAN.

I moved to XML from csv because there was a problem (now fixed) with memo fields.

Its a nice robust way of doing things, and if I really screw up (I have once or twice) I simply copy the entire live system and alter paths etc

Roy Lambert