exporting data from file to file

[Ben Ball]

What is the quickest/easiest way to import records from one filemaker database to another?

 

I have 2 solutions with identical tables with identical fields etc..?

 

i.e.. if you were cloning a database.. how can I get the records from the original that i need and put them into the related tables??

[Lee Smith]

Saving your database as a clone should have no effect on the data, i.e. it should go with it, unless you make a no record clone.

[Ben Ball]

Oh.. its not that I need to.. I am using an existing solution.. cloning it with no records...

 

but i need some of the data from the main database that I cloned from.. but not all of it.. as i will be making changes to one database... but not the other..

 

so i need to import a lot of records from many different tables...

 

whats the best way? export as csv then import it? it makes sense for importing to different languages...

 

but from filemaker to filemaker..is there a quick way? or automatic way? this will need to be done on a regular basis...

[LaRetta]

Hi Ben, 

 

You need to script looping through layouts based upon each table, showing all records, exporting data as MER or CSV and then repeating on the import side, also remembering to reset the serials (if you are not using a UUID).

 

Is this an on-going process or a one-time thing?

[Ben Ball]

Hi LaRetta..

 

ok.. so it is a case of exporting and importing...

 

Yes.. it will be an ongoing process... and it could get annoying for people?? unless its auto..

 

I guess If I create some layouts just for the tables I need to export from... it could make things more tidy..

 

as they could be numbered up. and added to if necessary.. the same on the other side..

 

but I don't want the user to see all the fields... like where they select what to import...??

 

how can i stop this? and make it auto?

[LaRetta]

 

but i need some of the data from the main database that I cloned from.. but not all of it.. as i will be making changes to one database... but not the other..

 

so i need to import a lot of records from many different tables...

 

And this will be an on-going process?  Wow, Ben, sounds like a PIB.  Can you explain a bit more … it is possible that we know easier ways of handling that functionality.  

[Ben Ball]

OK, well.. its 1 company... but in 2 locations.. doing exactly the same jobs... using the same core information...

 

to save duplication.. I know the best way is really to have a seperate solution.. where they both look into the common info..

 

but its slow.. due to internet etc..

 

so basically.. info will be put into one system... but then will need to be updated in the other also... once these changes are made..

 

ideally... as "fool proof" as possible..

[webko]

How poor is their internet?

 

I quite happily use a system that is on a server in the US from Australia...

[LaRetta]

Hi Ben,

 

I do not have enough information to properly advise.  You are talking about more than simple import (I believe) … more like synchronising the data and if these records are being served to multiple users at both locations, you can run into timing issues, to say the least.

 

Really there are ways to optimise solutions served and I would suggest exhausting that possibility first rather than attempting to keep an ongoing-developed solution in synch between two locations.  If you insist on this approach, check out some tools (and maybe you already have) such as MirrorSync.

 

ideally... as "fool proof" as possible..

 

It may be time to call in a professional to help you decide the best approach (and even write it for you) since mistakes with either process are major.  Nothing is fool proof so just be sure you hire the brightest fools you can find. LOL.  I wish you the best with your project.

[Ben Ball]

ok, thanks for you help..

 

I wont have timing issues as such.. its just mainly so that the users don't have to duplicate information... if they create a record in one system.. they also need the same info in another.... so just need to send the new info into the other system.. to save creating new records.

 

It will only be for 3 or 4 tables... not the whole thing.. there are 100's of tables in this database.

 

so It may not be a major problem... but I dont like that the users have to select how they import data... like selecting, by name, matching fields etc...

 

thats my worry... they have the option... I can't see how you can bypass this in a script..?

 

I have tried importing CSV option. which I think will work the best. but it wont export the field names... which I need..

 

only in xl does it give the field names?

[comment]

but I dont like that the users have to select how they import data... like selecting, by name, matching fields etc...

 

thats my worry... they have the option... I can't see how you can bypass this in a script..?

 

You can set the Import Records step to be performed without a dialog - if that is your only worry (I am not entirely sure of that, but we only know what you tell us).

[Ben Ball]

No.. well actually.. I have a lot of worries now...

 

I really need to get something sorted in the interim..

 

The main problem now.. is as follows..

 

1. I have 1 table with many fields. When I export XL it does'nt take all the fields. When I export CSV I can't import it to the correct locations. Also, it does'nt take the field names at top.. and there is no option to do so.. So how can I effectively import a csv file into filemaker and ensure the correct fields import into the correct fields...

 

2. If you can import tables from database to database.. why not records directly?

 

3. if the XL/CSV file is not exported in exactly the same way as the filemaker fields.. then its hard ot get them all to match... even though.. they are all identical.. same QTY.. same names.. same everything.

[comment]

I don't know where you get all this. First, you can certainly import records directly from another Filemaker database (provided it's available). Next, I don't understand why exporting to Excel would not "take all the fields" (other than container fields, but you will get this with any other format except Filemaker).

 

Re #3, you only need to match them once - and not change the order of fields after that, neither for the export nor for the import. Of course, It's easier when you use a format that includes the field names - such as Filemaker or XML or Merge. IMHO, Excel is far from being the best choice as an interim format.

[Ben Ball]

apologies.. I think I got my self in a pickle...

 

I was just trying my options... CSV is the most common way of getting info form different programming languages... that I know anyway..

but it does'nt seem so easy to import it in...

 

I have found a good way of doing it.... which is the filemaker route.. I just did'nt know how...

 

I exported a .fp7 file called the table I wanted to export...

 

then just imported that file into the relevant table.... I did'nt realise I could do that... this works a treat for what i needed...

 

when I first put up about importing records from database to database.. I hoped someone may suggest the filemaker way to do it... I think I over complicated the question.. but its hard to explain