Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB Enhancement Requests and Suggestions » View Thread |
Messages 1 to 3 of 3 total |
EDBMgr "Create Copy of Table ..." should copy triggers as well |
Wed, Apr 23 2014 11:32 AM | Permanent Link |
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. Barry |
Wed, Apr 23 2014 11:58 AM | Permanent Link |
Adam Brett Orixa Systems | 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 ... |
Thu, Apr 24 2014 2:45 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |