I set a variable $filepath first using... Get ( DesktopPath ) for saving out files. I have never run a remote script before though.
Thanks. The "Get(DesktopPath)" tip was worth your post all by itself. I spent an hour earlier today writing a complex function that provided me with the same info.
Thats a good one. I don't believe it can be scripted.
There are a few options though. In the Manage → External Data Sources, you could alter the file path for Fishes of the World to include all of the possible file paths. Note it will open the first one it finds in order of the list you give it.
Another ability is to open files with a relative path, which is good if you know the current file will be together with the Fishes of the World file.
Alas, I may be well and truly,,,well never mind.
The files are in two separate folders, though on the same level. But alas, this is an old project and the previous caretaker password-protected the project after disabling a number of menu options, including the manage data source dialog. Then, he failed to let anyone else know what the password is.
Nevertheless, thanks for the tips. They are options I had not considered because I did not know about them.
Well, I found it in the documentation; powella is correct. Variables are not allowed in the path descriptions of data sources so it looks like I am going to have to find another way to make this happen. Thanks all of you who participated in the discussion.
no, they are not. use globals, and/or pass variables with the Script Parameters.
Thanks, Beverly for your rersponse. If, however, variables are not allowed in a datasource path, how would using globals or passing scripting parameters make any difference? I don't mean to be insulting. I'm new to Filemaker and I honestly don't know.
Sorry, I misunderstood, pedantic. You have the SAME file on various desktops. Why is this not on FMS or on one machine with peer-to-peer sharing? then there would be ONE path for all. Files would be relative to each other (regardless of folders, or included in the path). I guess I want to know why each person has their own copy of the same file...
No problem and thanks for asking.
Here's a short description of the step-by step process:
1.) We get a bunch of CDs from a vendor. There is a one-to-one correspondence between the CD and the customer. So I have a CD for John, a CD for Cathy, a CD for Fred, and so on. Each CD has unique data that only belongs to John or Cathy or Fred, etc.
2.) Before we can use the data on that CD to do our part in the manufacturing process, we have to pass that data onto our customers in a way that is easiest for them to edit. So we create FM runtimes for each person, one for John, one for Cathy, etc. In the past (that means in FM6) that meant we make one runtime and then swap out the database after processing the data on each CD received from the vendor.
3.) So instead of building one big databse with hundreds of customers' info in the same database, we have several separate databases (and several separate worker bees) that import data from the vendor CD, process them and then spit the processed data out to the runtime. We copy the runtime onto a CD and mail it to the customer who massages the data and returns the information to us by email in an XML file.
Why didn't we do it the way you suggest? Probably because the first person to start programming this system was new to the whole database universe and didn't know he could. Then why didn't we change it once we knew better? Well the Navy has an apothegm that is probably how management thinks in this company: "if it ain't broke, don't fix it." The system worked, and worked well, so why change it?
I also suspect that the separate-CD-per-customer might have influenced the design decisions.
So why change it now? The FM6 system does not work (I am told) on the most recent versions of OS X. AND the company wants to do the least amount of work needed to make it work on FM11 because there is discussion about trying something completely different, someday...whether that will happen is something to be decided at a (much later) date and is out of my hands.
So for now I am trying to make the FM6 code work in FM11.
I hope that answers the question.