9 Replies Latest reply on Aug 7, 2014 12:05 PM by philmodjunk

    Windows Import cache?

    PaulaS

      Title

      Windows Import cache?

      Post

           I'm working in a cross-platform environment; our server is Windows; all v11. A couple of weeks ago we moved to a new building (don't know if significant or coincidence). A script that had been pulling a FileMaker file from the server to import stopped working correctly for Windows users (Mac users have not experienced the problem).

           The purpose of the script is to export/import a list from one record to other records. The user has a list of issues in a portal on their page, they click "export" and it exports the list (small group of records) to a file using their account name - over-writing any file that's already there - out to a location on a company server. I have checked and it exports correctly.

           They go to another record, click "import" and it should import the records from that file. What it appears to be doing is importing from some old file I can't seem to find.

           Then, after a couple of hours, it will start importing the file it was supposed to.

           It's not linked to any particular record or file from what I can tell, so that leads me to think it's some sort of memory on a Windows machine.

           Any ideas?

        • 1. Re: Windows Import cache?
          philmodjunk

               There's no need that I can see to export and then Import. Import Records can move the data from one FileMaker table to another without having to first export the data. The source and target tables can be in the same file and it still works.

          • 2. Re: Windows Import cache?
            PaulaS

                 If there's no easier way to fix this, I need some help with the script rewrite. I thought it would be a good way to avoid setting an ID to more than the desired number of records, seeing that this can be happening across many users.

            • 3. Re: Windows Import cache?
              philmodjunk

                   I have no idea why such a script would only work part of the time and only have an issue for Windows users. There's not enough info here to suggest to me a possible cause for that.

                   What I am suggesting avoids the issue by simplifying the process by removing one of the steps--which coincidentally makes all the file references used ones that can be set up as relative file path references which are much less sensitive to changes in where a file might be located on your system.

                   I also have no idea how your database is designed where it might affect this particular process. But from here, it appears to me that you'd have the same concerns whether you export, then import or just import the data.

              • 4. Re: Windows Import cache?
                PaulaS

                     Please provide more details as to how to do this. I'm not sure the best way to import records to a portal of a new record without first exporting them to another file.

                • 5. Re: Windows Import cache?
                  philmodjunk

                       Please describe the design of the tables and relationships involved so that I can then provide those details.

                       In general terms, the same step that imports them from a new file can be redirected to import from a table occurrence's found set in your current file. you simply select your current file instead of the file created by the unnecessary export.

                  • 6. Re: Windows Import cache?
                    PaulaS

                         I have a Projects table with a one-to-many relationship with the Revisions table (screenshot attached).

                         The user creates the Revision records in a portal on a layout based in the Projects table.

                    • 7. Re: Windows Import cache?
                      philmodjunk

                           Do you then need to:

                           a) create a new project record and

                           b) import (copy)  the revision records from a different project so that they are related to this new project record?

                           If so, what determines which project record's revisions should be so duplicated?

                           And is the new project record also duplicated from a previous project record?

                      • 8. Re: Windows Import cache?
                        PaulaS

                             What they do is start in one Project record with the comments they want to duplicate and click "import/export"

                             they choose "export"

                             A pop-up comment box asks which kind of comments to export ("All" or "Unresolved Only" - based on a field value), then they can choose a category (based on functional area, which is another field value)

                             they navigate to another (existing) Project record and click "import/export" and choose "import"

                             the comments appear on the portal in that Project record, alongside whatever comments were already there

                             They can navigate to as many other projects they want and import the comments from their export

                        • 9. Re: Windows Import cache?
                          philmodjunk

                               I see that my ideas were taking us right off the edge of a cliff here. I had not stopped to consider that the records you are exporting and importing are all from the same table. FileMaker will throw up an error if you import from table A into Table A telling you that a table cannot be imported into itself. blush

                               BUT, no import at all is needed here. Your script can duplicate each of these records, updating the duplicated copies to correctly link them to the selected Project record.

                               

                                    A pop-up comment box asks which kind of comments to export ("All" or "Unresolved Only" - based on a field value), then they can choose a category (based on functional area, which is another field value)

                               I would assume then that the script performs a find or uses Go to Related records to pull up a found set of those records for the revision records matching the specified criteria. No change will be needed to this part of your script.

                               

                                    they navigate to another (existing) Project record and click "import/export" and choose "import"

                               When they click what I assume must be a scripted button labeled "Import", the script can do the following:

                               Set Variable [$ProjectID ; Value:: Projects::ProjectID //use your field name here in place of mine ]
                               Go to layout ["Layout with found set of revision records here"]
                               Go to record/Request/Page [First]
                               Loop
                                  Exit Loop If [ Get (FoundCount ) = 0 ]
                                  Duplicate Record
                                  Set Field [Revisions::_fkProjectID ; $ProjectID ]
                                  Omit Record
                                  Go to Record/Request/Page [First]
                                  Omit Record
                               End Loop

                               That's the basic idea. Of course this also eliminates your found set of revision records pulled up at the beginning so you can only do this once, as written, not for several different projects, but there are a number of fairly simple ways to bring back your found set so that you can do this again.

                               Options for restoring the found set:

                               a) Store the criteria used in global field or variables and then you can perform the find all over again.

                               b) store the list of primary key values for your revisions records as a list in a global field in a related table, then go to related records can be used to bring them back up. In FileMaker 13, this is particularly simple due to the addition of a new kind of summary field.

                               c) use a second table occurrence of Revisions, a layout based on this added TO and Go to Related records to "clone" the found set to the other layout to "save" the found set and then you can do the reverse with GTRR to bring it back.