Importing when source table not present...

[ron G]

I have about 15 tables that are accessed via script through an import script.

Everything works well *UNLESS* there is no source table. Then the user needs to press 'Cancel' and go on to the next table import.

Question: "How can I script something like "If the source table <> target table then cancel"

I am stuck. Can someone give me some 'light'?

Thanks

[bcooney]

My question is, how can there be no source table "sometimes." What are your sources and why are they different?

[ron G]

My question is, how can there be no source table "sometimes." What are your sources and why are they different?

My application is in 'beta'. And, I have had to change the structure by adding 4 tables that were not in the previous releases.

Users who get the current version (.888) try to IMPORT the records from their previous version but when the Source does not

contain the tables in the Target, the users get confused and usually import whatever table the Source shows. In this situation

they should just 'cancel' and move on to the next import command in the import script.

Thanks for your help.

[David Wikström]

You can use the formula:

TableNames ( Get ( FileName ) )

to know which table occurrences are present in a file. This should allow you to do what you need, though I also find it difficult to imagine a scenario, even in beta, where there is a good reason to end up in a situation where you would need to do this. But there's always something new to discover in FileMaker.

Depending on the record data set size and your need for speed, you could also play with the idea of using a loop and set field (by name) instead of doing an actual import.

[bcooney]

You could also capture the version from which they are importing, and conditionally import.

[ron G]

You can use the formula:

TableNames ( Get ( FileName ) )

to know which table occurrences are present in a file. This should allow you to do what you need, though I also find it difficult to imagine a scenario, even in beta, where there is a good reason to end up in a situation where you would need to do this. But there's always something new to discover in FileMaker.

Depending on the record data set size and your need for speed, you could also play with the idea of using a loop and set field (by name) instead of doing an actual import.

Thank you for the ideas.

The code segment works great --- for getting the tables in the TARGET file. But, of course I already know the tables in the target because it is from the target that my Import Script is being run. The problem is getting the Windows/Mac file path to the user specified Source file and then doing a comparison.... (The comparison is the easy part)

The 'good reason' for such a situation comes about when several beta testers express a desire to have a feature included that requires additional tables. Or, in this situation, when I 'assume' that FM will somehow let me Import Custom Value Lists into an updated version. Wrong. Hence the additioinal Value List Tables.

You say "you could also play with the idea of using a loop and set field (by name) instead of doing an actual import." I don't get the context of this statement. Specifically, the user is going to import an unknown version Source into a Target table. Some of the tables in the Source do not match with the Target (they are present in the Target and NOT the Source).

So, how can I loop through the Source (unknown) table and setfield (Target)? Or, did you mean something else? As you can see, I don't understand what you are suggesting. Can you amplify your statement?

Thanks

You could also capture the version from which they are importing, and conditionally import.

Absolutely right! Unfortunately I did NOT create a global::Version field until this version of the program. Up to this point, versions were indicated by a text box on the main screen. Yep, knowing the version would let me know which tables are in the Source and Target.

Nice idea. Thanks

[bcooney]

Version should be in a regular field (number, perhaps) in a single record table, not a global. Or, perhaps part of the filename? Have you seen the upgrade demo I posted a while ago?

[ron G]

bcooney:

Thanks for the link. The 'demo' looks like something I can learn a lot from studying. (My printer is dead until Feb 22 so I will have to wait)

RE: the version being a 'regular' field in a single record table.... Why? What difference does it make? It seems that the version number would be useful in a comparison like: If (global:version < .800).... else .... endif. This would allow me to adjust my import script to the file structure of various 'versions' of my program.

Or, is my thinking off base?

Thanks again.

Ron

[bcooney]

You can rely on global field values in a single-user system. In a hosted system, they default to the last value set when the file was closed single-user, and are typically set for each session in a File Open script. They are not as reliable a value, imho, as a regular field in a single record table.

[dansmith65]

I like this method of storing the version of a database: http://filemakerstandards.org/display/bp/Default+scripts

One benefit of it is that the version # is stored with the schema, not with the data. So, if you were to save a clone of the database, the version # would not be lost with this method.

[bcooney]

That is nice.

[ron G]

RE: File version stamping. Very interesting.

But, does anyone know of a way to programatically evaluate if a Source:Table DOES NOT have a table found in the TARGET:Table when the Import Mapping dialog is present? Or, when it is NOT present? My impression is "I can't get there from here"; ie, it isn't possible.

[dansmith65]

But, does anyone know of a way to programatically evaluate if a Source:Table DOES NOT have a table found in the TARGET:Table when the Import Mapping dialog is present? Or, when it is NOT present? My impression is "I can't get there from here"; ie, it isn't possible.

TableNames ( "SourceFileName" )

But... If you use the update process from bcooney's demo file, you shouldn't have to.