Filemaker Output
Hi Experts,
I have a client that has an old Filemaker 12 database, we are replacing it with an SQL system. We need some kind of export of all the data inside the old one. The person who created it is not cooperating, and we're having trouble finding anyone that knows enough about Filemaker to do so. We have an account for the DB with admin rights, but no idea where to start. We don't really care what format the output is in, as long as it's something we can read to CSV or Excel and prepare for import into the new system.
Is there some kind of script or function we can run to export ALL the tables to some friendlier format?
Thanks!
I have a client that has an old Filemaker 12 database, we are replacing it with an SQL system. We need some kind of export of all the data inside the old one. The person who created it is not cooperating, and we're having trouble finding anyone that knows enough about Filemaker to do so. We have an account for the DB with admin rights, but no idea where to start. We don't really care what format the output is in, as long as it's something we can read to CSV or Excel and prepare for import into the new system.
Is there some kind of script or function we can run to export ALL the tables to some friendlier format?
Thanks!
North2Alaska
I can understand the feelings of the previous owner, but what you are asking for is not unreasonable. That said, yes you can export the data. Can you get to the relationship graph? You need to start there.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you for your responses.
Will, we've started an export of the first table as you suggested, So this will work, but it's pretty slow. The current table has about 8000 records, and it does about 1 per second. There are some other tables in the database that we know have 80,000+ rows. My guess is that it's slow because we're doing this from a client machine, Are you aware of any tools that could perform directly from the server side? Like you would with SQL Server Management Studio?
Thanks!
Will, we've started an export of the first table as you suggested, So this will work, but it's pretty slow. The current table has about 8000 records, and it does about 1 per second. There are some other tables in the database that we know have 80,000+ rows. My guess is that it's slow because we're doing this from a client machine, Are you aware of any tools that could perform directly from the server side? Like you would with SQL Server Management Studio?
Thanks!
Working from a client machine using hosted files will definitely make the export slower. The best speed will be from having a copy of the files open locally in FM Pro as opposed to connecting to a server via "Open Remote..."
The other thing that will make the export slow is if you are exporting summary and calculation fields. Assuming you have access to File -> Manage -> Database you can look at each table and see the field types. There is no reason to export Summary fields at all as they are generally used for reporting and rely on other fields only. Also look for calculation fields that reference other tables. These may have been added for reporting, appearances, dialogs, etc. and are most likely unnecessary as they also reference other fields and do not contain raw data. Global fields also do not need to be exported and container fields will not give you anything of value in a CSV export.
If you don't have access to the full field list you might be able to determine which fields are summary and calculation based on naming convention, but only if the original developer choose to use one. One convention is to include a suffix such as "_s" for summary fields or "_c" for calculation fields.
The other thing that will make the export slow is if you are exporting summary and calculation fields. Assuming you have access to File -> Manage -> Database you can look at each table and see the field types. There is no reason to export Summary fields at all as they are generally used for reporting and rely on other fields only. Also look for calculation fields that reference other tables. These may have been added for reporting, appearances, dialogs, etc. and are most likely unnecessary as they also reference other fields and do not contain raw data. Global fields also do not need to be exported and container fields will not give you anything of value in a CSV export.
If you don't have access to the full field list you might be able to determine which fields are summary and calculation based on naming convention, but only if the original developer choose to use one. One convention is to include a suffix such as "_s" for summary fields or "_c" for calculation fields.
ASKER
Ok, great. This really helps!
Thank you!
Thank you!
If you have full access, you could set it up as and ODBC source and point a SQL tool at it to do the extract.