Moving data from DB to clone

[jrb66]

Hi,

I am totally inexperienced when it comes to FM... Nevertheless, I have been tasked with moving all the data (4 GB in 120 tables and 530 layouts) from a database (FM 9) which had to be recovered into a known good clone of the database (previous backups were corrupt).

Can anybody point me in the right direction to accomplish this task? Are there scripts available which will do this relatively painlessly. I am not in a position to really create such a script from scratch but would be able to tweak things - hopefully.

I don't see an option in FM to transfer all the data at once - just one table at a time. Or, am I just missing something.

Any and all suggestions would be greatly appreciated.

Thanks,

jrb66

[LaRetta]

This is NOT a job for the faint of heart or someone inexperienced. If the data is important at all, hire a Developer. There are no real shortcuts. You must export the data one table at a time (I prefer .MER format). Then import into new clone without 'perform auto-enter.' And you must reset the serials. If you make a mistake and forget to reset the serials, your data becomes trash. And once Users start USING the tables again, their data cannot be retrieved (and unscrambled from the old data) without a lot of work.

I am totally serious. Unless you have a weekend you can block aside without any User activity, AND unless you can verify and triple check every table, don't risk it. You must also map from the .MER files to your new tables which is okay if you match on names. But there will be things forgotten and tweaks which will need to happen, ie, containers and globals. If I wished to truly curse my worst enemy, I might suggest it. I've done many of them (unfortunately). Even if you have the scripts in place to automate it, surely as the sun rises, you will have added fields (which will be missed during the imports) or you will have changed field names (and your maps will break) anyway.

LaRetta

[LaRetta]

I can recommend a top Developer if you PM me. I'm unsure whether he is available but your data will be safe in his hands. I regret to say that some Developers are no better than attempting it yourself. The decision is yours alone.

You might also post here on Forums for someone. Or even read many posts to get a better understanding of which Developers are good. However, unless you yourself are pretty good, you won't always know a good one from one that is ... not.

Edited June 26, 2008 by Guest
Added paragraph :o)

[Vaughan]

The most common error is forgetting to reset the serial numbers for primary keys etc. The result is that, after the import, new records might have serial numbers that are duplicates. This will show up as users reporting that new records seem to magically get related records (don't let them delete them!).

The best bet is to go through the tables in the old file and look for serial numbers. Open the field definition and record the "next" number. After the import, open the tables in the new file and reset all the numbers to their "next" values.

Make lots of backups, frequently, and give yourself lots of time.

[LaRetta]

Hi Vaughan!

Thank you for adding the reasoning on the reserialisation issue. I started to but I'm trying to shorten my posts. There were also several other things I could warn about but I'm practicing concise.

LaRetta

[jrb66]

LaRetta and Vaughan,

Thank you for your replies.

It appears that I will be needing to locate a developer to remedy the situation. Now to convince the management level folks......

Even though I do not plan (at this point) to touch production data, I may just attempt, for practice only, to recover a few of the tables to learn what is actually involved. If you have any other words of advice, feel free to educate me.

Your help has been very much appreciated.

Thank you so much for your input and advice.