Matt Klein Posted June 16, 2004 Posted June 16, 2004 I have a FileMaker Pro 7 solution. One of the scripts I wrote imports records from one table to another in the same file. When I run the script on the "Host" computer everything works GREAT! When I try to run the script on a "Guest" computer the import doesn't happen. On the guest machine, I then look at the script that has the import step in it and I click on the Specify Data Source pop-up and select File. The reference to the correct file is there. When I close this dialog box, I get an error that the file can't be found. So, I click on Add File, then Remote... and select the file from the list then try to close the dialog box again and get the same error. FYI, when I select the file in the Remote... dialog it doesn't put the fmnet: reference in the Specify Data Source dialog it only puts the file: reference. So, I tried manually typing the fmnet: reference. Then, as soon as I try to close the Specify Data Source dialog box FileMaker just quits on me. What am I doing wrong? Anyone?
Papabjoe Posted August 5, 2004 Posted August 5, 2004 I am having the same problem. The import script works fine from the host machine, but I am having the exact problem you described fromt he "guest" machine. Any solutions?
Matt Klein Posted August 5, 2004 Author Posted August 5, 2004 The only solution I can see at this point is using a relationship and a looping script to create the records from one table to another instead of importing them. These are the types of things that are keeping me and my company from moving to seriously developing in FileMaker 7. FileMaker fixed some other issues I had with 7 in the v2 patch. I can only hope that v3 is coming soon. It's not worth our time to develop in 7 until they get some of the most basic items working like this one.
JanB Posted August 6, 2004 Posted August 6, 2004 I'm so happy to learn that it wasn't ME but very very unhappy with FM for releasing this version with such a GLARING hole. Thank you for your responses. I can now stop banging my head on the desk. I've spent an age trying get this to work!
alta_flyer Posted August 26, 2004 Posted August 26, 2004 Hi Lwlgeorge, I am having the exact same problem with trying to use a "HOST" computer and 5 remote computers for data entry and have installed the 7.0v2 patch. I tried about 20 different relationships and nothing worked. Can you briefly describe the relationship/looping procedure you refer to ?
Fenton Posted August 26, 2004 Posted August 26, 2004 This was posted on another list, by Ilyse Kazar, who is an advanced expert. It does not answer your question about how to the Loop, but is a clear exposition of the problem:
Matt Klein Posted August 26, 2004 Author Posted August 26, 2004 Well, I am surprised you were able to run an import at all on a guest machine. I can't get it to run the import at all. As I said in my initial post to this thread, I was getting an error when selecting the file in the Import script step and when I manually typed in the fmnet: path to the file, the application unexpectedly quits. On top of that, I am working with one file. I'm just trying to import from one table to another. So, your example doesn't quite apply to me. Rather, it brings up another bug in the Import functions of FM7. I am going to the Developer Conference this weekend. I am going to talk to a Technical person from FileMaker while I am there. If I find anything out, I will post it here late next week.
Matt Klein Posted August 26, 2004 Author Posted August 26, 2004 You can define a relationship from the source table to the target table making sure to check the "Allow creation of records in this table via this relationship" box on the target table side of the relationship. You also want to be sure that the field in the target table side of the relationship isn't a calculation, Summary, or Global field otherwise you won't be able to create the records in the target file. I would set up the relationship(CreateRecords) to go something like Constant in the Source Table to CreationField in the Target Table where Constant is a calculation with a result of "1" and CreationField is a Text Field. Then, I would write a script that loops through the records in the Source Table that you want to "Import" into the Target Table that sets the fields in the Source file to the contents of the fields in the Target Table using the relationship CreateRecords. It might look something like: Enter Browse Mode[] Go to Record/Request/Page[First] Freeze Window Loop Go to Field[CreateRecords::Field1] Go to Portal Row[Last] Set Field[CreateRecords::Field1, SourceTable::Field1] Set Field[CreateRecords::Field2, SourceTable::Field2] Set Field[CreateRecords::Field3, SourceTable::Field3] Go to Record/Request/Page[Next; Exit after last] End Loop That script assumes you run it while on a layout in the SourceTable that has a portal using the CreateRecords relationship on it with a vertical scroll bar and CreateRecords::Field1 in the portal. There are a couple of limitations of scripting the "Import" as shown above. FileMaker allows you to update records using the Import routines and a match field. This script doesn't work for updating records. That would be an entirely different and more complicated script. Also, you cannot control Auto-enter fields in the Target Table. If you use the Import function, you can check a box that prevents the Auto-enter fields from Auto-entering. Using the script above means that Auto-enter fields will Auto-enter. Hope this helps some.
alta_flyer Posted August 29, 2004 Posted August 29, 2004 Thanks for the Info. I noticed some of this same behaviour on some of my other scripts ! I was wondering re: the program shutdown when "REMOTE" import from one table into another. If using the "COMMIT RECORD" step would have any effect on this problem. Unfortunately my client is in another city and I don't have access to a local network right now to test my theory ?
Matt Klein Posted August 31, 2004 Author Posted August 31, 2004 Well, I am at the DevCon and I talked to a technical person from FileMaker. All I can tell you is that they are working on it.
Recommended Posts
This topic is 7389 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now