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

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

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

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