Thank you for the post.
To attempt to replicate this I performed the following test:
1. Created a new database file called "exceltest.fmp12"
2. Used the following script:
Set Variable [$path; Get (DocumentsPath) & "Invoice.xlsx"]
Export Records [No Dialog; $path]
3. Specified .xlsx format as the output for the Export Records script step.
4. Tested locally on the iPad
5. Uploaded "exceltest.fmp12" to FileMaker Server 12.0v1
6. Tested from FileMaker Pro 12 with file hosted on FileMaker Server 12.0v1
7. Updated to FileMaker Server 12.0v3
8. Tested from iPad connected to file hosted on FileMaker Server 12.0v3
Perhaps I am missing a step to replicate?
Thanks for your email, but it still doesn't work over here.
It always yields in an Error Code 3: "Command is unavailable (for example, wrong operating system, wrong mode, etc.)".
Below is a screenshot of the exact script I'm using.
Again, this works just fine on OS X, but it doesn't work at all on iOS. I've tried it on both iPad and iPhone, both running the very latest version of FileMaker Go. When I trap for the error code, it yields an Error Code 3.
I've also tried changing "Get (DocumentsPath)" to "Get (TemporaryPath)", but still nothing.
My privilege set is [Full Access], so I definitely have privileges for exporting records.
This is apparently some nasty bug in FileMaker Go, but it is only affecting this particular file. If I create a brand new file from scratch, it works just fine. So there's something specific to this particular file that is making it fail. I have no idea what it could be... only thing I can think of is that this file was originally created in FileMaker 11 and then converted to FileMaker 12 format, whereas the brand new file started off in FileMaker 12 format. I've checked for errors using FileMaker's Check Consistency command, and everything is just fine. I've also deleted and rebuilt the script from scratch, but still the same thing.
The only other thing that I can think of is that the Output file character set is set to "Unicode (UTF-16)", but it's DIMMED and it won't let me change it!! Could this be the problem? I have no idea why it is dimmed, and no idea why it won't let me change it. See below screenshot.
And, here is the other part of the "Export Records" script step. Nothing unusual here. Only thing unusual is that Unicode thing in the previous screenshot.
Oh never mind about that Unicode thing... it always switches to Unicode when you choose .xlsx as the export type.
I'm really at my wit's end here... I'd love to send you a sample of this file, if you could take a look at it! :)
Thank you for the replies.
Report an Issue is for reporting product bugs. If the issue can not be replicated in a new database file, then we have narrowed the issue to a database specific issue and not a product bug.
If you are able to replicate this behavior outside of the current database file, using a new database file built in FileMaker Pro 11 (then converted to 12) or newly built in FileMaker Pro 12, then please let me know and I will be happy to take a look at the newly created sample file.
This file passes FileMaker's consistency check, but does the file pass recovery? Corruption is the most likely cause of a file specific issue that does not occur once rebuilt in a new database.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
1. The recovered copy may behave differently even if recover reports "no problems found."
2. Recover does not detect all problems.
3. Recover doesn't always fix all problems correctly.
4. Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
What to do when your file is corrupt (KB5421).
Hi, I've been working with the amazing TSWildcat on this issue... he has been able to reproduce the issue, and the bug crops up on a locally-running FileMaker Go file... doesn't need to be hosted at all. He thinks it has something to do with the file size of the file. If the file size is too large, you can't export from FileMaker Go.
Any details on how big is "too big"?
Not sure... we're waiting to hear back from QA, which is where TSWildcat forwarded my file.
But this particular file is 2.62 GB in size.
It's weird to me that the bug crops up BOTH locally (when the file lives on the iOS device) AND remotely (when we access the file remotely from FileMaker Go to a remote server). I would think that if the file was too big, then it wouldn't truly make a difference if it was in a hosted environment, just if it was local to the iOS device.
But I guess we'll see what QA has to say!
But won't the file be exported to a location in the iOS device in either case?
Is 2.62 GB the size of the file being produced by the export or the size of the file from which you are exporting the data?
If the issue is connected to the size of the file produced by the export, how does that file size compare to the available storage capacity of the iOS device?
(Just trying to nail down the details here so that I can write this on up in the Known Bugs List.)
Perhaps filesize was the wrong term. The size of the file in MB isn't all that large however it does contain a good deal of schema. The reason I tied the size of the file with this issue is that myself and TSfalcon were unable to reproduce in new files.
I've forwarded Scott's file on to QA with the hope that we will get a proper explanation as to why this is happening and rule out any speculation as to why this issue happens in this database and not others.
Yes, that is true... the file will be exported to the iOS device in either case, so it does seem to make sense that the bug would happen regardless of where the FileMaker file is physically residing.
2.62 GB is the size of the FileMaker file from which I am exporting the data.
The resulting .xlsx file is absolutely tiny: Only 5 kb in size. (We're only exporting a tiny amount of data... just a few fields are being exported, and less than 100 records are being exported.)
Each iOS device that I tried to export from had a minimum of 7.5 GB available on the iOS device. One of the iOS devices had 12.2 GB available.
Just a simple 2-line script fails on iOS, as you can see in one of the previous screenshots I posted. But it works just fine on OS X.
Ah, gotcha! Thanks so much, TSWildcat! You are awesome!! I responded to PhilModJunk before seeing your message above.