folks, we have two dbs: source.db & target.db. we need to kinda copy records manually from source to target by using a button. how can we do that?

details on that: source.db has lots of records. we want to be able to select one (no problem for us) and put it over to target.db (problem for us). idea: using the source.db's recID in target.db, getting the rest by relations/references.

problem: creating a new record in target.db and putting the recID. and all this from source.db with a button ... oh, and: we'd like to avoid (beeing on a macintosh) using applescript ....

any help appreciated.

thx, phonoguy.

Hi Phonoguy,

You can accomplish this by using a global to store your RecID from your Source current record. There must be a relationship from Source to Target. It doesn't matter what the relationship is since globals will 'appear' to every record. If you don't have an existing relationship established, just create a cConstant calculation (text) in both dbs with 1. This calculation in Target must have Index ON.

Once the relationship is established, go to your Target db and create a global (match RecID data type) field called gSourceID. Then create a script in Target called New Record, similar to:

New Record/Request/Page

Set Field [RecID, gSourceID]

... then use Set Field to set all your other fields (based upon a relationship from this RecID to your other related dbs) and then finish with...

Set Field [gSourceID, ""]

Then in your Source db, create your button script, which would be:

Freeze Window

Set Field [Target::gSourceID, RecID]

Perform sub-script External ["Target.fp5"] and point to your New Record script

Refresh Window

Upon attaching this script to a button, your Users will create a new record in Target but won't be able to see it happening. And the script will terminate with them still on the same record in Source.

LaRetta

Oh, I should have also mentioned ... To be nice to your Users, add a Show Message at the end of your button script with "This record has been copied to Target" with only the OK button (default). Otherwise, they may not know it's been done!

LaRetta

Another way to approach this is to simply import the records in the found set in Source into the Target file. There are a couple of ways to set up the import. I assumed you want to maintain unique "id" values for your records, i.e., no duplicate id's in either file.

If you set up your import to match the "id" field of incoming records with the "id" field of existing records in the Target file, then matching records in Target will be updated with the information in the incoming records. Any incoming records not matching on the "id" field will be added to the Target file.

I wasn't clear if you want to keep the original records or not, so in the attached demo you have the option of keeping or deleting the original Source file records.

No AppleScript needed

Hope this helps.

Move_Records.zip

laretta, jim,

thank you very much for the tipps (in german: with two p). i'll go into both solutions later this week and will let you know, how it worked out.

phonoguy.

Hi 'Phononguy',

What works the best... well, for over 15 years (starting with FMPlus v2), I've had a need for 'removing' unused records from an 'active' file... but keeping these unused records in an 'inactive' file for future reference. I've tried many things... creating relationships, copy & paste (and variations), and using export & import.

The winner is... 'export & import'!

I utilize an automated (scripted) export & import process... basically...

- give users a way to 'mark' the records to be 'moved'

- use scripts to 'move' marked records from source file to target file

-- source file "export" script:

--- find marked records

--- export found set to text file, FMP file, etc.

--- open target file

--- run target file script

-- target file "import" script:

--- import text file, FMP file, etc.

Other info...

- This system works well to perform text backups of your FMP solutions or for moving your data from one solution version to another solution version via text files.

- The scripts can be 'spruced-up' with warning/progress dialogs to the user.

- The scripts could have additional steps to find unused data records.

- The scripts could have steps to delete the source records once moved to the target file.

Hope these ideas give you some insight... Good Luck!

Bob Kundinger

[email protected]

bob, thank you for your post. we are using ex-/import as well. but since our solution is multi-user-based, we came to a serious problem: in fm it is not possible to name the export-result individually or even store to a location other than prerecorded *during the export-process*. one has to use i. e. the troi-file-plug-in, later on, to achieve renaming and moving files (<- please correct me if i am wrong on that). in general i love export/import a lot but in this special case .... :-(.