With FileMaker 18, this is no longer needed. Almost every time we would set up a FileMaker Server, we would set up this additional database folder ahead of time. Thus, if we used the path of the file in an import script step, it would allow us to import data. And because the new folder was inside the Documents directory, the FileMaker file hosted in that directory would cause externally stored files to be placed in the same sub-directories. In the past, to get imports to work we would add an additional database folder and have it point to the Documents directory. (When a step is grayed out it indicates that the step is not compatible to run in that location.) Unfortunately the ‘Export Field Contents’ script step is still not server compatible.Įxport Field Contents In hindsight, if the ‘Export Field Contents’ script step were supported on the server then we could have used that step to export the file from the container field to the temporary directory and then passed the file path to the import script step for it to import the data. When you perform the ‘Export Records’ script step on the server it can only output to the documents directory or the temporary directory.Īnother interesting side point is that the temporary directory comes into existence only when referenced by the script and once the script completes then the directory vanishes without a trace. Similarly, exporting data follows the same restrictions. When executed on FileMaker Server, imports can only reference files that are in either the documents directory or the temporary directory. Not everyone’s cup of tea, I realized, and a number of people reached out to help them get it set up correctly. In a follow up blog post we shared more PSoS techniques, including how to set up the additional database folder to get imports to work on server. A few years ago we covered how imports on FileMaker Server are definitely worth it, especially for improving speed:ġ00x Faster – Flight Testing FileMaker Perform Script on Server – Part I With file-based script steps in FileMaker 18, you can perform imports natively, and take advantage of Perform Script on Server. If you have seen me present at a past DevCon you’ll note that I like to use intersection diagrams to explain how things fit together: Not only is my favorite number 13, but Perform Script on Server (PSoS) was introduced in FileMaker 13. Let’s start at the beginning! My favorite FileMaker version happens to be 13. Password: import A Brief History of PSoS and Imports Here is a demo file you can use to try out the techniques: Like it or not, we can’t always escape the flood of cheap spreadsheets, but maybe we can build more efficient FileMaker integration with output from tools like Excel. In this blog post, I’ll use the new FileMaker 18 file-based script steps combined with PSoS for a little import magic, and hint at how to improve data-driven workflows. Performing imports like this, natively, means avoiding the traditional performance overhead that would tax both FileMaker Server and FileMaker users over a WAN, and otherwise require waiting for imports to complete, synchronously. You can also take advantage of Perform Script on Server (PSoS), and handling imports asynchronously. I was thrilled to discover in FileMaker 18 that the new file-based script steps give us the ability to perform imports natively on FileMaker Server, with no configuration or changes needed. Combining functions, features, or steps in creative new ways can deliver productive results.
0 Comments
Leave a Reply. |