![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 8 of 8 total |
![]() |
Mon, Mar 29 2021 9:09 PM | Permanent Link |
Ian Branch | Hi Team,
My Customer's database is getting quite large. Perhaps not as large as some, but large nevertheless. Is it possible to do a selective Backup and later Restore in some manner? The idea being to Backup and then delete all table records prior to say 01/01/2010 from multiple tables so they no longer exist in the current database, but, if required at a later date to be able to restore those tables/records into the Database without negatively impacting existing tables/records. Regards & TIA, Ian |
Tue, Mar 30 2021 2:29 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Ian
My first thought would be to look at EXPORT and IMPORT After that it depends on why you want to do it. If its to save disk space then you need to do something that will allow the data to be physically removed. If not, and its just to speed things up a bit, what about creating clones of the tables you want to reduce and move the data into them - if you use the date range as part of the file name you could allow users to select a file/set of files to report on. After you've deleted the unwanted data from the live tables don't forget to optimise them Roy Lambert |
Tue, Mar 30 2021 2:54 AM | Permanent Link |
Ian Branch | Hi Roy,
The prime objective is to reduce the overall Database size. I will have a look at Export/Import. Regards, Ian |
Tue, Mar 30 2021 2:58 AM | Permanent Link |
Ian Branch | I have had a look at Export/Import. Might be problematic.
I just had a thoughty, perhaps I could export the data to DBISAM tables, assuming there is adequate field/data type compatibility. Just thinking out loud here... |
Tue, Mar 30 2021 4:45 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Ian
<<The prime objective is to reduce the overall Database size.>> <<perhaps I could export the data to DBISAM tables>> Why use DBISAM? How about this as a process: 1. create clones of tables that you want to archive data from 2. copy the data you want from the live tables 3. delete the copied data from the live tables 4. optimise the live tables 5. create backup of the archived tables / copy the backup tables somewhere 6. drop (or DELETEFILE) the archived tables Roy Lambert |
Tue, Mar 30 2021 9:42 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Ian
Minor change 0. Have clones of tables that you want to archive data from 1. copy the data you want from the live tables 2. delete the copied data from the live tables 3. optimise the live tables 4. create backup of the archived tables / copy the backup tables somewhere 5. EMPTY the archived tables Roy Lambert |
Tue, Mar 30 2021 3:55 PM | Permanent Link |
Ian Branch | Hi Roy,
Understood. Thank you. Still contemplating the issue. Ian |
Tue, Mar 30 2021 4:13 PM | Permanent Link |
Raul ![]() | On 3/30/2021 3:55 PM, Ian Branch wrote:
> Hi Roy, > Understood. Thank you. Still contemplating the issue. What Roy proposed (or something similar based on same principle) is best way to go. EDB backups are more complex than DBISAM since table schema is not part of table (like in EDB) and there is also what EDB calls a table version related to actual schema changes to the tables. This is one reason why you should always backup the catalogue but also makes it very complex to bring back single table(s) or such. Raul |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |