7 Replies Latest reply on Jan 8, 2014 11:57 AM by FritzMills3

    Problem when importing .txt using script

    LabsRock

      I've been around and around with this one because I keep thinking I'm missing something obvious. I'm scripting the import of a rather large set of data from a tab separated text file. I tested the import by running it manually and everything went fine. But when I include the same import as a script step it seems to go through the motions, showing the progress on how many bytes have been imported (just like in the manual run), but when it gets done there are zero records in the table. If I then go in and run it mannually again, using all of the same settings as the script that just ran, I get the 94,000+ records.

       

      I'm beginning to wonder if the file is damaged and will probably test that next. Has anyone ever run into a similar problem? Is there check box somewhere I could have missed?

       

      Thanks in advance for any input.

       

      Craig

        • 1. Re: Problem when importing .txt using script
          wimdecorte

          Is there an "import.log" file that has more info on what went wrong?  Also check what error filemaker reports right after you import script step.

          1 of 1 people found this helpful
          • 2. Re: Problem when importing .txt using script
            LabsRock

            Thanks to both of you for your responses.  After posting I tried one thing I should have done sooner, I deleted the script step and recreated (pretty much what Egbert suggested).  Everything ran fine at that point.  I did save a copy of the file before doing this (the version that wasn't working) so when I have some time to dig in a little deeper I will run again and follow your suggestions Wim.  For now I've got to move forward and hope this was something that won't crop up again now that it seems to be working correctly.

             

            Thanks again.

             

            Craig

            • 3. Re: Problem when importing .txt using script
              FritzMills3

              I have a somewhat related problem. I created a script for importing tab-delimited .txt files that works just fine with FMP 13. However, when I uploaded the file to FMS 13 and tried to run the script (connecting thru my local copy of FMP), it complained that, "This file could not be translated using the selected file type". When I moved the FMP file back to the local machine and opened it with FMP, it imported the file just fine. I have not tried manually importing from the server and then recreating the script step, but the idea of having to recreate imports every time I develop something locally and then upload it to server is not very appealing to me, and might not always even be practical.

              • 4. Re: Problem when importing .txt using script
                wimdecorte

                FritzMills3 wrote:

                 

                I have a somewhat related problem. I created a script for importing tab-delimited .txt files that works just fine with FMP 13. However, when I uploaded the file to FMS 13 and tried to run the script (connecting thru my local copy of FMP),

                 

                That's a little confusing.  If the file is hosted on FMS but you still run the import from the client then the server has nothing to do it with.  It is still the client doing all the import actions.  Just the data is sent to FMS.  FMS makes no decision whatsoever on the file format of the file you want to import.

                 

                So the fact that the file is hosted is a red herring, the problem is elsewhere.

                 

                If you were running the import script as a server-side script schedule then it would be different: then it is the FMS script engine that looks at the file presented for import.

                • 5. Re: Problem when importing .txt using script
                  FritzMills3

                  Ok, the problem may be elsewhere, but I can't figure out what else I might be doing wrong. The server is brand new, maybe a week old, running all the latest latest. I posted a 2-minute movie of my screen at…

                   

                  https://www.youtube.com/watch?v=PljZ8GmAajI&feature=youtu.be

                   

                  It shows me:

                   

                  1. Opening the file on the server via the client FMP, invoking the script and getting the error

                  2. Closing the file in FMP, then closing the file in FM server admin, and copying the file to my local HD

                  3. Opening the file locally via the same client FMP, invoking the script and running it correctly.

                   

                  So the FM file, when served by FMS, throws an error, but when the exact same file is opened locally using the same copy of FMP, it works. It's the same client and it's the same FM file and it's the same .txt file, so I don't get it. I'll send you a copy of the file if you want (and a copy of the text file I import). The only possible difference I can think of is that I'm running Mountain Lion on the client and Mavericks on the server. But that shouldn't be an issue, should it?

                  • 6. Re: Problem when importing .txt using script
                    LabsRock

                    I think it is certainly worth trying the import manually from the server.  Is the file you are trying to upload in the same relative location in both circumstances (FMP and Server)?  However, my guess reading the other post from Wim and your response is that the problem lies somewhere with the file you're tring to import (and more likely) its location relative to the FM Server/FM Pro.  If the file is in two locations during this process (i.e. you're moving a copy of it as well) then double-check the extension after moving (and permissions?).  If you're importing from the same location check that it is referenced correctly, probably using a variable rather than hardwiring it.

                     

                    Craig

                    • 7. Re: Problem when importing .txt using script
                      FritzMills3

                      There's only one copy of the text file I'm trying to import and it's on my client machine. Its location with respect to the cliient FM Pro, which I use to open the Filemaker file and run the script both when the Filemaker file is being served and when I've opened it locally, is identical. This is not a new script. I've been using it on to do local imports since last May. It's just that I just installed FM Server 13, and decided to upload the Filemaker file and run it from the server. The text file itself is a Mail message that I've saved as text. It is a log file from my firewall. I get anywhere from 3 to 9 logs emailed to me each day, and I save them all to text files and import them into my Filemaker file. As I say, I've been doing this since last May and never had an issue. It wasn't until I tried to host the Filemaker file on Server and run the script there (using the same client copy of Filemaker Pro Advanced as before) that the problem arose. And, after the import fails on the server, I can close the Filemaker file on the server and open it locally, and the import succeeds. Same Filemaker file; same copy of of FMPA 13, and same text file. Watch the movie I posted. You'll see what I mean.

                       

                      However, I did have some success trying to import manually and the script is fixed now. Basically, when I initiated a manual import from the server, it defaulted to showing all available file types, and the file wasn't greyed out, but when I chose it I got the error. So I went back in and told it to only show tab-delimited text files, and then it imported it OK. So then I went into the script and unchecked Perform without dialog, saved it and ran the script. When the dialog came up, I told it to only show tab-delimited text and the import succeeded. Then I went back into the script and re-checked Perform without dialog, and now the script works. I still think there's something wrong, but at least it's fixed.