I am using FM 12 advanced

 

I have a Membership application.  It has a global table that holds things like:  Organization Name, Address, City, State, Zip, Phone etc...

 

The problem centers around the fact that there are multiple versions of the program.  If I 'release' version 22 it is released with sample data for first time users.  But, a previous user needs to import their data from the previous version 21. 

 

I just discovered tonight that my global table (which only holds global fields) has 18,000 records.... all duplicates ....   Yikes. 

This is the result of my treating the global table like any other table when I did my import.

 

 

But, I don't know the best way to a) delete all the fields in the target global table and then import the current record in the Source table.  I don't see any record level controls in the Import Script function... Or, am I missing something?

 

Your thoughts and ideas are appreciated.

 

Ron

 

 

 I don't see any record level controls in the Import Script function... Or, am I missing something?

 

What would those be?  What are you looking for?

 

The typical approach when transferring data into a new version of the solution is to first script a delete of all the records in the new version and then import from the old one.

Absolutely right! 

urns out FM was right.  I *was* importing tens of thousands of records... all from the global table. 

I had neglected to delete the Global table PRIOR to importing it.  That meant that 1 record was copied and became 2.... 2 became 4... 4 became 8.... 8 became 16.....etc. 

Once I deleted all records in the global target table I still could not get the source table to import.... grrrrr....  Then I realized I needed a record set to import into.  So I just did a New Record/Request.

 

The import script looks like:

 

Go to Layout ["GlobalNew (Global)]

Import Records [No Dialog; $$path' Add; DOS OEM]

Delete All Records [No Dialog]    // deletes all records but since they are global they 'persist' in the table.  I 'still' don't get this?

New Record /Request    // makes the global values 'useable'

 

This sure does seem to work.  Is my reasoning sound?

 

Ron

I suggest that you do not rely on a table to store globals. For each global field, I have a corresponding non-global field in a separate Prefs table. I set the global fields to the non-global value in an Update Globals script, which is typically a subscript to my File>Open script.

And on the downside of storing 'globals' in a prefs table is that the 'true' globals must be initialised with a script - this won't happen have if your file is opened due to a relationship.

 

Effectively there's a script trigger that is missing - OnFileOpen.

 

It's always been missing.