I just registered and am a new user -- I hope this is a place to ask questions among other FM Pro users.

I am having a problem when importing from one FM Pro database to another. The problem doesn't happen a lot, but causes us grief from time to time. We have a large number of FM Pro databases on a FM Pro Server. When we create an invoice, we run a script that imports information from another FM Pro database to the "invoice" database. Occasionaly information ends up in the wrong fields. We get descriptive information in a pricing field, for example. It is usually the same two fields that have the problem.

Anyone know of this problem?

I have had very similar frustrating problems with both importing and exporting. I won't go on, but some of the problems we experienced were really erratic. I posed the question to several discussion groups to which I belong without receiving any responses.

The only solution we came up with after many days of trial and error was to not use import/export to do the job. We ended up creating scripts to copy field values to globals and then populate fields in a receiving database. This is a much safer solution and works 100% of the time with 100% accuracy.

Hope this helps.

Sometimes the lack of response is due to a lack of information.

Are you using a script to import? More than one script? Are you using an intermediate file? Have fields been added to either file between runs of an import script?

Properly used, import should be completely reliable. -bd

If you use import or export in scripts, any time you add, rename, delete, or change fields to calcuation fields, you need to redefine the import/export order in the scripts. Otherwise the orders are based on the old field list.

Thank you for all of your comments. It is not a matter of having added new fields. The databases are pretty stable. We generate hundereds of invoices each week, importing data from one database to the other in each case via a single script. One a couple of invoices per week, the data from one field appears to import into the wrong field. Thereafter we can continue on without a problem. There is no "intermediate file" but perhaps I should consider it.

If there are any other comments, I would appreciate it.

This is a multi-user setup right? Are the errant imports done while the system is being used by more than one user perchance?

This is a mutli-user system running on a Macintosh based Filemaker Server. The database that the data is coming from during the import is open and in use by many workstations. The database that the data is going into is accessible to many, but in reality there is only one person who really uses it or has it open. I guess it is possible that mutliple people could have it open when the errors occur, but it is unlikely.

It's a good thought. You'd think that record locking might cause one or more records to be omitted from the export, but why would fields be scrambled, especially the same two.

I'd almost guess something else is going on here. It like a description over the phone of a patient with a headache. When you see that patient in person, he has a 20d nail sticking out of the back of his head that wasn't mentioned! -bd