Importing Specific Records ONLY

[Hijack]

I'm trying to figure out a way to import only specific records from one database to another.  Both databases are the same file but may contain partially the same data as well as different data.  I know I can manually open the import source, find the records I need to import as the current found set and the import just those. The question is, how can I do this via a script? 

 

I can't expect the users of the database to do the same manual search and find and I can't specify the import source as a known data source to the "pull" database.

 

I can script the import of the master table that holds the source IDs off of which all child data is related into a temp table in the pull database and compare the IDs in the pull database to the import source IDs and find which are new in the import source.

 

How can I feed those IDs into the import source as find criteria?  I can't run scripts in another FileMaker database unless I define the external file as a known data source.  If I import duplicate records with the same IDs with data in the pull file and then delete them after the import, existing related data will get wacked.

 

Any suggestions?

 

Thanks all.

[jbante]

I'm confused about what you're asking for. You say, "Both databases are the same file," but then "I can't specify the import source as a known data source to the 'pull' database." If you're importing from one table to another in the same file, what's the problem? If you're importing from one FileMaker file to another, why can't the import destination file reference the source file? The source file does not have to be listed as an external data source to be used in the Import Records script step, just to call a script. Is it OK for the source file to list the destination file as an external data source? If so, then the process can be initiated from the source file rather than the destination file. If the source file needs to get find criteria from the destination file, the source file can call a script in the destination file that returns those criteria as a script result.

 

I'm I understanding you correctly that you want to create an import that has the effect of only importing new records, but not updating existing matching records? Another possible way to accomplish that might be to import all the source data into a temporary table in the destination file, reducing the temporary table's found set to new records, and importing those to the destination data table; this would eliminate the need to pass an ID list to the source file. Whether the performance of this is acceptable will depend on how many records you're working with and the typical new/existing record ratio.

[Hijack]

Jeremy,

 

Thanks for the reply.  It is a strange situation.  When I say that both files "are the same", what I meant to say is that they are two copies of the same file.  The database is intended to be a completely independant file without links to anything external.  I would like to be able to allow users to share content that they create independantly but each user would have a common set of content that comes pre-loaded with the database.  I need to find *just* the content that's new so that duplicate data is not created on import.

 

I've thought about importing to a completely different set of tables but that's a daunting task considering the complexity of the database.  I've also considered creating an "export" function to make a file for import into another system.  I've looked at prompting the user to delete the common data from the source first.  All solutions don't seem very elegant.

 

What I'm leaning toward right now is adjusting all of my relationships to include an "Imported" field which would be set to a static "NO".  All tables would have this field and it would be included in all the joins.  I could then do a bulk import of all records, do a replace in the Imported field after each table is imported and change it to "YES" to break the relationship so I could loop through imported found set and kill the records that have same IDs as existing data without risking deleting data via relationships.