Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 4 of 4 total |
Migration problems |
Fri, Sep 26 2008 10:05 AM | Permanent Link |
"Jeremy Knowles" | In trying to migrate a DBISAM4 app to EDB, I've a problem or two...
First, using EDB Manager, I made a database with some tables, and created a backup. Then I decide to import some DBISAM tables, so I use the migration tool, with the path and table passwords set correctly. There seemed to be no confirmation of what was happening, and it seemed to do some tables but not others, with no information as to what had not imported. Then some other tables appeared on the list but not all, so I try to migrate again, and it tells me the first table on the list already exists, which it does because it migrated it the first time, but some others didn't, so why does it just fail at that point? I then imported some other tables from another folder, and got similar things happening. OK, so I go back to the backup and try again. EDBM tells me that it couldn't lock the database for exclusive use, and I haven't a connection anywhere else, so it's EDBM that has a session open, so couldn't it close it for me, or give me the option to do so? Instead, I eventually realised it was this, closed the connection and did the restore (the second time ticking the restore catalog tickbox, since it the first time it didn't remove the newly imported tables). I try again and firstly it tells me it completed successfully, but no tables appear, and a second time I get a #100 error saying there's an error in the metadata for a table and that the migration did not complete. I'm also seeing more tables on the explorer tree than in the right pane, though the 'number of tables' in the task list thing is the same as the tree (incidentally, can we hide this or something when looking at the table data as there's little room for the data on screen?) I clear the tables out and try again and get a error #1004 'The primary key constraint primarykey for the table xxx has been violated' (which isn't true, I checked the DBISAM data and there are only 6 records in that table) Incidentally, whilst EDBM remembers where it was last time when you open it, it isn't multi-monitor aware so it always starts up on the left monitor if you have it full screen, if you can change that, it'd be nice. I will continue to persevere, but it's not been too happy a migration so far, and can't believe this is the norm, so any advice welcome! -- Jeremy Knowles |
Fri, Sep 26 2008 12:54 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Jeremy,
<< First, using EDB Manager, I made a database with some tables, and created a backup. Then I decide to import some DBISAM tables, so I use the migration tool, with the path and table passwords set correctly. There seemed to be no confirmation of what was happening, and it seemed to do some tables but not others, with no information as to what had not imported. >> There's an issue with the migration progress/status updating in the EDB Manager as well as an issue with migrating tables with BLOB fields when you include the row data, so I would suggest that you simply hold off on trying any migrations until 2.02 is released, which should be Monday or Tuesday. Two major changes, the script debugger and the changes to use a new StringBuilder for building strings, really screwed up things good with 2.01 B5 and, needless to say, I'm not real happy about it right now. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Sep 29 2008 5:26 AM | Permanent Link |
"Jeremy Knowles" | Tim Young [Elevate Software] wrote:
>There's an issue with the migration progress/status updating in the EDB >Manager as well as an issue with migrating tables with BLOB fields when >you include the row data, so I would suggest that you simply hold off on >trying any migrations until 2.02 is released, which should be Monday or >Tuesday. Two major changes, the script debugger and the changes to use a >new StringBuilder for building strings, really screwed up things good with >2.01 B5 and, needless to say, I'm not real happy about it right now. Tim That makes sense, yes, I've removed the table with blobs and the rest imported fine. It would be good to be able to pick specific DBISAM tables rather than doing them all, although I got around this by dropping them one at a time into a new folder and migrating, but it was a bit of a pain, since I had to set the path and table password every time. I'll get on with something else and look forward to the update... -- Jeremy Knowles |
Mon, Sep 29 2008 11:21 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Jeremy,
<< That makes sense, yes, I've removed the table with blobs and the rest imported fine. It would be good to be able to pick specific DBISAM tables rather than doing them all, although I got around this by dropping them one at a time into a new folder and migrating, but it was a bit of a pain, since I had to set the path and table password every time. >> We didn't do so initially because of the RI aspect in non-DBISAM source databases. However, I am going to add this option in one of the next minor releases. It's going to require a minor release because of changes in the migrator calls to allow for table listings, etc. << I'll get on with something else and look forward to the update... >> Thanks for your patience, and my apologies for the issues. B5 included some feature updates that should have waited for 2.02, but were included due to time constraints. It was, in retrospect, a mistake to do so. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Monday, May 6, 2024 at 12:23 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |