targetTableName = "Calendar" ;
" SELECT DISTINCT BaseTableName " &
" FROM FileMaker_Tables " &
" WHERE BaseFileName = ? " &
" ORDER BY TableId " ;
"" ; ¶ ;
Get ( FileName ) & Case ( PatternCount ( Get ( FilePath ) ; "fmnet:") ; " (" & Get ( HostName ) & ")" )
PatternCount ( ¶ & currentFileBaseTableName & ¶ ; ¶ & targetTableName & ¶ )
Ron, this is along the lines of what I replied over at FMforums.com
Obviously you can't run this query from inside the new file as that would require a file reference. But you can have the script in the old file and then call it from the outside without requiring a file reference. That's where the fmp protocol, ActiveX and Applescript options come into play.
Inside the file you are wanting to import and check the existence of the table do something like this
set variable $_tables to get(the table names) Sorry not at filemaker right now
In the table you want to perform the import do this script
PerformScript see above
set variable $_result to script result
Now you have a list of table names such as
Now you can do an exact comparison on each item to see if it is what you are looking for.
This requires adding the two line script to the other table. You may bullet proof it with a few more steps.
Thank you for the specific idea.
I tried creating my own ExecuteSQL query but ran up against the problem of 'not' having the Target on the Relationship
Graph and I don't see any way, using Native FM code, to get it there.
How do you get the user selected file onto the Relationship Graph?
Thanks for the reply. I always find your contributions interesting and usually valuable.
I looked into Applesceript and ActiveX (My app runs in Windows and OSX). FM Help says "The primary benefit of ActiveX Automation in FileMaker Pro is the ability to initiate FileMaker Pro scripts from outside of the FileMaker Pro application.. Sounds promising. But, then it says "Note To implement ActiveX Automation with FileMaker Pro, you need to be proficient in a programming language such as Visual Basic or C++". I am proficient in neither and my organization does not have the funds to purchase either and I don't think I have the time to become proficient in either.
In my efforts to try and track down a native FM 'way' of solving the problem, I got an idea from Kris Hayward at Coresolutions Software. I've been deciphering how it works and it seems promising. I attach it if your are interested.
Thanks again for your ideas.
It seems there are several issues to this question.
Let's assume that you have full access privileges or sufficient for the following.
Select from the File menu, Import Records: File...
When the file opens... under the target menu I can select to create this table in the current file. Select the Target Popup and drag down to the next to last item to create this import and a new table in your file. You can rename the import TO later.
Will this get you closer to your quest?
I realize I can do it manually.
But, the crux of the problem is to be able to do it via FM Script.
To that end I was given this sample: https://www.dropbox.com/s/e1q84zhjsqp3feq/test.zip
I think I will work. But, I don't 'get' how the Test2 table <<File Missing>> was created. I think this is called a 'file reference to a static file'?
No, you cannnot do what you propose.
Wim has described your options.
Thanks for the reply.
It does beg the question "How do most developers provide for an upgrade to their apps when they: a) add a new table to their 'new' app and b:) need to import users 'old' data into the 'new' app? Is Wim's ActiveX/Applescript method the _only_ way to do it?
Importing data can be done by a script. If the old data lacks fields in the new table, those fields remain empty if they are not autofilled. Check the import function.
Can other applications add fields and tables to Filemaker? I don't think so but then I've never wanted to try and so can't answer that. I would hope that fields and tables cannot be added by other applications to a Filemaker file.
It is easy to add a new table/file to a solution using the TO concept.
My belief is that the best method of development uses a multip-file setup. One for just the data and one or more for GUI files. A GUI file can be created or modified without affectng other GUI files and if you need to add a table, just add it to the GUI file if it is only needed for one Privilege Set, say accounting. You can add it to the data file later.
It is saner and safer to create an external but linked file/table and debug it and any scripts and then transfer them to the working file when eveyone is off for the day.
To be correct: I mentioned ActiveX and AppleScript (and also the FMP URL protocol) as ways to run a script in a file without needing a file reference to that file.
That's only sideways related to the import question.
Typically a new table in the updated file does not interfere with the importing scripts: these all target the existing tables. The import routine in the new file would not attempt to import something into the new table.
The next version of the new file that you will release at some future date would then have added code to also import that table. That's a version control thing more than anyting else. You don't need to release the new version with code that would import from a non-existent table.
RE: Importing data can be done by a script. If the old data lacks fields in the new table, those fields remain empty if they are not autofilled. Check the import function.
In my app, I have a Members (parent) table and several 'child' tables. If I add a new child table, to a new version of the program, when I run the import script in debug, as I get to the import step that calls for the importing the 'non existent' table in the Source, FM responds by trying to match up Members as a Source and consequently matches 'inappropriate' data with the existing fields in the Target. Therein lies the problem. None of the matched fields are 'autofilled'.
I would be pleased if FM would pleased if I could get FM to have the target fields "remain empty" in this situation. So, I must be doing something wrong?
Thanks for the reply
I store version numbers in my files. If you import in the version number from the old file you can then use an If statement to determine what table to import. An example would be:
If (old version number < version number when the new table was created)
import the old tables
import the old tables and the new tables
Apparently I hold some misconceptions as evidenced by the following:
I have a 'new' version that has an addressbook table.
I have an 'old' version that _also_ has an addressbook table.
The first thing the AddressBook Import script does is load the AddressBk layout and delete all the records. This works.
As I step through my script (in debug) when I get to the IMPORT (dialog turned on) command I see that FM has specified Members as the Source Table? Huh?
So I select a SOURCE of AddressBook. It works.
I run the script again. Same default to Membership as a Source.
What do I have to do to get FM to 'find' the Source table? (I have checked Bob Bowers FM 12 Dev Reference and Jessee Feiler's "FM 12 in Depth")
Perhaps this is the crux of my misunderstanding....