Just for your information.



I used for converting DB from Oracle to MS SQL standard export-import
technology.



That was in 3.0. I duplicated and partly rewritten standard import algorithm
not to make RecId conversion and not to make transaction ID conversion. Just
imported data with the same RecId and transaction ID into new company. After
that I run RecId recalculation, which was also modified for better
performance.



Such a way is acceptable if you transfer the whole company, not only adding
part of data to existing company.



I reached import speed at above 1000 records per second. It is about 3.6
million records per hour. Or about 1 Gb per hour if assume average record
size to be 400 bites.



But not changed RecId and transaction IDs allows to spread tables into
different definition groups and parallel export and import. For example, for
10 Axapta clients 10 Gb per hour is not so bad.



As I can see in 4.0 something like this may be used for conversion.



Several times I used this technique to transfer data for testing from the
customer. This kind of import is much faster than standard.

Just for your information.



I used for converting DB from Oracle to MS SQL standard export-import
technology.



That was in 3.0. I duplicated and partly rewritten standard import algorithm
not to make RecId conversion and not to make transaction ID conversion. Just
imported data with the same RecId and transaction ID into new company. After
that I run RecId recalculation, which was also modified for better
performance.



Such a way is acceptable if you transfer the whole company, not only adding
part of data to existing company.



I reached import speed at above 1000 records per second. It is about 3.6
million records per hour. Or about 1 Gb per hour if assume average record
size to be 400 bites.



But not changed RecId and transaction IDs allows to spread tables into
different definition groups and parallel export and import. For example, for
10 Axapta clients 10 Gb per hour is not so bad.



As I can see in 4.0 something like this may be used for conversion.



Several times I used this technique to transfer data for testing from the
customer. This kind of import is much faster than standard.

Just for your information.



I used for converting DB from Oracle to MS SQL standard export-import
technology.



That was in 3.0. I duplicated and partly rewritten standard import algorithm
not to make RecId conversion and not to make transaction ID conversion. Just
imported data with the same RecId and transaction ID into new company. After
that I run RecId recalculation, which was also modified for better
performance.



Such a way is acceptable if you transfer the whole company, not only adding
part of data to existing company.



I reached import speed at above 1000 records per second. It is about 3.6
million records per hour. Or about 1 Gb per hour if assume average record
size to be 400 bites.



But not changed RecId and transaction IDs allows to spread tables into
different definition groups and parallel export and import. For example, for
10 Axapta clients 10 Gb per hour is not so bad.



As I can see in 4.0 something like this may be used for conversion.



Several times I used this technique to transfer data for testing from the
customer. This kind of import is much faster than standard.