mac Possible to Save 'Save Records as PDF' to Server?

[Craig Wall]

I was a foolish boy to assume that using a local relative path would easily translate when moving a file from a local context to the server. The script now returns error 800.

 

If I hardwire a path location in the script can I save the PDF to the server?

[Richard Fincher]

I am interested in the answer to this question also.

[Craig Wall]

Richard, you and I are in this together! I've been surprised that this isn't easier nor commonly discussed. It's an ideal scenario for the paperless office. 

 

To this point my research is discouraging as it seems to suggest that the only solution would require users to have the server hard drive mounted.

[Richard Fincher]

I guess it depends on what you're doing with the PDF after it's been created. If the PDF is created in order to email it, I guess it doesn't really matter where the PDF is created. But if you want to save it in a repository which is common to all users of the system, that's different. But you'd have to deal with issues of multiple logged in users attempting to save a file with the same name into the same shared directory. You wouldn't get this when separate client-based working directories are being used.

[Wim Decorte]

To this point my research is discouraging as it seems to suggest that the only solution would require users to have the server hard drive mounted.

 

Much depends on the OS of the clients and the server.  On windows you can easily push files to a network share without mounting (or mapping), by just using the UNC format of the share:

 

serverNameOrIPshareName

 

Assuming of course that the user has the proper rights to the share.

 

So what OSes are involved on the clients and which one on the server.

[Craig Wall]

I guess it depends on what you're doing with the PDF after it's been created. If the PDF is created in order to email it, I guess it doesn't really matter where the PDF is created. But if you want to save it in a repository which is common to all users of the system, that's different. But you'd have to deal with issues of multiple logged in users attempting to save a file with the same name into the same shared directory. You wouldn't get this when separate client-based working directories are being used.

 

I'm using dynamic file names, so there's no danger of users knocking into each other. And yes for my client the repository concept is key... 

 

It's been quite a learning curve for me: the script moves across four different layouts and uses the append feature to build up a very involved PDF. It's encrypted too. I thought I was past all the tough challenges and then I move it to the server and DOH!

Much depends on the OS of the clients and the server.  On windows you can easily push files to a network share without mounting (or mapping), by just using the UNC format of the share:

 

serverNameOrIPshareName

 

Assuming of course that the user has the proper rights to the share.

 

So what OSes are involved on the clients and which one on the server.

100% Mac Server and clients. And me.

[Richard Fincher]

In my case, it's a Mac server, with windows clients.

[Craig Wall]

I am wondering if the following approach might be best:

 

1. Use the local client computers for intermediate storage of the PDF. The PDF would get e-mailed from off the local machine.

2. Filemaker would then grab the final PDF from that temp storage and throw it into a container field on the server. (The container field would be configured for external storage)

 

If...if I can script all that...the only downside aside from my labor and fuss... is that I'd need to get staff members to dump that 'cache' folder on their drive every year or so. 

[Wim Decorte]

is that I'd need to get staff members to dump that 'cache' folder on their drive every year or so. 

 

Not really.  Easy enough to script an OS-level cleanup for the temp folder you choose.

 

The rest of the approach is feasible, with one big question: is it your expectation that people can interact with those PDFs *OUTSIDE* of FM?  If so it's best not to use FM's external container data storage.  That feature is not meant to be about document management, just like regular live FM data files, FMS should be the only process touching the remote container data files.

[Craig Wall]

Not really.  Easy enough to script an OS-level cleanup for the temp folder you choose.

 

The rest of the approach is feasible, with one big question: is it your expectation that people can interact with those PDFs *OUTSIDE* of FM?  If so it's best not to use FM's external container data storage.  That feature is not meant to be about document management, just like regular live FM data files, FMS should be the only process touching the remote container data files.

No need/expectation for people to open/utilize PDFs outside of FM.  I'd like to continue this dialog tonight or tommorrow ...and I'll hope to contribute some ideas as well as questions. Thanks Wim, Rincher.

[Claus Lavendt]

Craig, if I read your initial question correct, you write that you want to create a pdf, that gets stored on the server.

Or in other words, have the server creating the pdf.

If that is correct understood, you have a challenge, since FMS does not support pdf generation.

 

You can create a script, that does this:

 

SetVariable [ $path ; Get ( TemporaryPath ) & "myfilename.pdf" ]

Go to layout 1

Save As PDF [$path]

Go to layout 2

Save As PDF [$path ; Append to existing file]

Go to layout, tied to the table, where you have the container field, where you want this pdf to be inserted. Maybe create a record, if needed.

InsertFile [$path]

...maybe go to original layout....

Send Email [ Setup TO, CC, Subject, Body as needed  -  Attach file: $path ]

 

No need to ask users to delete the temporary folder on clients computer, since FileMaker and OS will automatically delete this folder when user quits FileMaker. (that's the beauty of using TemporaryPath)

 

When defining path, you should prefix with filewin:/  or filemac:/  depending on the users current platform.  (needed for windows, not needed for mac, but good idea to just do it anyway)

Oh, and if you have a bunch of files, that reside in a folder, which you have inserted reference to from your local machine and now you have moved the FM file to a server, then these files would only be visible from your local machine. You can setup a container field to use external storage and then script Insert File in a loop and then transfer all your files from the referenced path to your FileMaker database container field.

[Wim Decorte]

No need/expectation for people to open/utilize PDFs outside of FM. 

 

Then you're all set.

 

There are two challenges:

1) generating the PDF - sounds like you have that under control.  As Claus mentions you can use the FM temp folder functionality for auto-cleanup (doesn't always work cleanly, but works for the most part)

 

2) storing the PDF: with remote container storage enabled, all you need to do is create a new record and insert the newly created PDF into the container.  FMS will store it on the server without bloating your FM file

[Craig Wall]

Craig, if I read your initial question correct, you write that you want to create a pdf, that gets stored on the server.

Or in other words, have the server creating the pdf.

If that is correct understood, you have a challenge, since FMS does not support pdf generation.

 

You can create a script, that does this:

 

SetVariable [ $path ; Get ( TemporaryPath ) & "myfilename.pdf" ]

Go to layout 1

Save As PDF [$path]

Go to layout 2

Save As PDF [$path ; Append to existing file]

Go to layout, tied to the table, where you have the container field, where you want this pdf to be inserted. Maybe create a record, if needed.

InsertFile [$path]

...maybe go to original layout....

Send Email [ Setup TO, CC, Subject, Body as needed  -  Attach file: $path ]

 

No need to ask users to delete the temporary folder on clients computer, since FileMaker and OS will automatically delete this folder when user quits FileMaker. (that's the beauty of using TemporaryPath)

 

When defining path, you should prefix with filewin:/  or filemac:/  depending on the users current platform.  (needed for windows, not needed for mac, but good idea to just do it anyway)

Oh, and if you have a bunch of files, that reside in a folder, which you have inserted reference to from your local machine and now you have moved the FM file to a server, then these files would only be visible from your local machine. You can setup a container field to use external storage and then script Insert File in a loop and then transfer all your files from the referenced path to your FileMaker database container field.

 

 

I hadn't known a thing about a temporaryPath. That looks VERY promising. Thanks!!!

Then you're all set.

 

There are two challenges:

1) generating the PDF - sounds like you have that under control.  As Claus mentions you can use the FM temp folder functionality for auto-cleanup (doesn't always work cleanly, but works for the most part)

 

2) storing the PDF: with remote container storage enabled, all you need to do is create a new record and insert the newly created PDF into the container.  FMS will store it on the server without bloating your FM file

 

OK. I'm ready to give this a whirl. Thanks gentleman!

[Craig Wall]

Well guys...SUCCESS! I still have a second place in the solution where I need to add the same functionality...and it will be a bit more involved. But I can see that this works and have it working in one part.

 

temporaryPath is THE BOMB. That is...A bomb that works peacefully and agreeably!