6 Replies Latest reply on Jun 17, 2014 11:43 PM by danielfarnan

    Anyone seen Export misbehaviour on Windows 7?

    danielfarnan

      Hi, all.

       

      I have a reported issue with exports on Windows 7, FMP v12. The user runs a script that isolates a set of records, sorts them and then exports 9 fields for each record, Windows ANSI format. The Export script step specifies "No dialog" and the export order, but does not specify a filename/path for the output file, meaning that when the script hits that step the user is prompted for an output location and a file type. The output location is being specified as part of the user's home folder, located on a remote drive mounted as <volumename><groupname> (H:)

       

      The reported issue is that the first attempt to export fails but subsequent attempts (usually) succeed. From the testing I have conducted, the failure occurs as described and _all_ subsequent attempts succeed - including (strangely) exiting the FileMaker application and relaunching the hosted solution. The failure of the export is the "<filename> could not be created on this disk" error.

       

      I am not a Windows expert but my intuition is telling me that the OS is tripping up the process. Given that the remote drive mounts at user logon (and I'm not yet in a position to test across multiple user logins) it might be that the first export attempt is trying to finalise something in the delicate dance that happens when a remote volume is accessed. Once that is done, all good (although not for all users, which is puzzling).

       

      Has anyone else encountered this behaviour? Any thoughts about the underlying issue?

       

      Thanks,

       

      Daniel

        • 1. Re: Anyone seen Export misbehaviour on Windows 7?
          mikebeargie

          I experienced this outside of FileMaker, similar issue though, where folders seemingly have read-only permissions when first accessed in a user session.

           

          This article may be of some assistance to you.

          http://itexpertvoice.com/home/fixing-the-windows-7-read-only-folder-blues/

          1 of 1 people found this helpful
          • 2. Re: Anyone seen Export misbehaviour on Windows 7?
            mark_b

            I run into this all the time with drives Mapped.  When I boot the system, I get a message something like Not All Network Drives were Loaded.  I go into Windows Explorer and there is a red X next to those drives.  All I do is open one of them and all is fine.  If I try to open a Filemaker document located in one of those mapped drives from Filemaker's "Open Recent", I get an error message that says something to the effect that it can't open the file.  However that doesn't happen if I have manually opened the "disk" from Windows Explorer.  I don't have a Filemaker workaround. Maybe a batch file could be set up to force open that drive.

            Cheers, Mark

            1 of 1 people found this helpful
            • 3. Re: Anyone seen Export misbehaviour on Windows 7?
              robwoof

              Given the helpful replies above, I have a suggestion that might be useful.

               

              Remember that when you specify a file path for export (or writing a PDF), you can specify multiple paths. FileMaker tries them in the order specified. If the first doesn't work, it tries the second, and so on until it finds one that works. If the last one doesn't work, then it throws the error.

               

              So the trick would be to use a set of paths some thing like:

               

              filewin:path/to/desired/remote/directory/actual_filename.txt

              filewin:<temporarypath>/test_filename.txt

               

              We know the temp path should work. So the only circumstance where test_filename.txt is present is if the save to the network drive fails.

               

              Then try loading the exported file into a global Container field, using the file references as follows:

               

              filewin:<temporarypath>/test_filename.txt

              filewin:path/to/desired/remote/directory/actual_filename.txt

               

              Check the filename in the global Container field - if it's actual_filename.txt, then the network drive export succeeded - we know this because test_filename.txt was not present in the Temporary path. If the global Container's contents are test_filename.txt, the network drive export failed, and the local export worked. That means you need to try again.

               

              For proper error-trapping, you would need to make sure the test_filename included something to make it unique (UUID or timestamp).

               

              Clear as mud?

               

              Rob

              • 4. Re: Anyone seen Export misbehaviour on Windows 7?
                danielfarnan

                Thanks, Mike - the generic advice from that article doesn't seem to be helping in this particular situation but it's a good starting point for further research.

                • 5. Re: Anyone seen Export misbehaviour on Windows 7?
                  danielfarnan

                  Thanks, Mark. Users are not encountering that particular message and I'm not sure if they have used Windows Explorer to access the folder before trying to export. But my intuition is telling me the solution is somewhere in this area.

                  • 6. Re: Anyone seen Export misbehaviour on Windows 7?
                    danielfarnan

                    Thanks, Rob.

                     

                    This is a little more convoluted than I want to try. I'm not sure how long to keep attempting the export, frankly - I'd probably try three times and then show an alert giving the user the option to try again, and that's not necessarily better than the current situation. I would also need to break the export process into multiple steps (identify the destination folder, then specify a filename, then export the data) and I'm reluctant to put that effort in when there's a Windows sysadmin on staff with the client.

                     

                    However, there's a chance I'll be taking this approach, so thanks for pointing it out.