The method I decided to use simplifies in some respects for the user but when they actually save the file in it's native application; I have no control of what they call it or where they decide to store it. I guess work flow discussions are in order. The client needs to understand how things work.

Yes, I understand that. But think of this. If a user hit the wrong update button (wrong portal row), he would re-insert the file int he temp folder. Similarly, if a user happens to hit the update button on a portal row BEFORE the temp folder was cleared (i.e. it has a document in it from earlier). That would be a bad thing. I'd like to make this as bomb proof as possible.

I can add a custom dialog to warn the user (make "cancel" the default), but still ... crap happens. That is why I thought if delete the content after re-insertion, there is less chance of them updating the wrong portal row.

If the file isn’t in the temp folder to insert, an error is generated. You can use set error capture to keep the message from appearing and use get (LastError) to detect it and take appropriate action If you wish.

Likewise, you can compare the filename in your path variable to the name of the file in the container to confirm that you are inserting the right file into the correct record’s container.

Attachments

I can’t tell from the screen shot whether the field on the left or the one in yellow on the right is the document name field.

make sure that it is a field of type text, not number.

It doesn’t take much for the values to not match. Checking results using the data viewer might help you spot the discrepancy. Calculation fields and custom dialogs may be used if you do not have advanced.

The yellow field is just temporary. It calculates the file name. I have it on the layout to test to see if the calc I used in the script works. I assume the calc amounts to the same result i.e. it works, but the script seems to be failing.

It seems you are well on the way to a solution, but just chipping in with a couple of thoughts. You mention the possibility of an updated file being put back into the wrong place, and also touching on the point made by Wim, that you don't have control over what users may do with a file they edit. My thought is that you could handle this in your update script by checking to see if the name of the file in the temp folder matches the name of the existing file in the container field—which presumably it would if the user simply edited the file and saved it. If there is a match, the file can presumably be safely reinserted. If it doesn't match—which could be for a number of user-driven reasons—then your script would notify the user that this is the case, and make them manually locate the file they wish to insert. If the notification also included notification of the name of the existing file, then this might alert them to the fact that they have clicked on the wrong row, say (but this possibility could be headed off by my next suggestion). A typical scenario might be that they clicked the edit button on row 3, did the edit, then accidentally clicked the update button on row 2 or row 4.

Another thought is that it would be worth (1) highlighting a portal row any time the edit routine is entered, and dismissing the highlight once the update routine is performed; and (2) prevent other users from even accessing the container file on any portal row/record which is between routines (i.e. Edit has been run, but Update has not). This would replicate FM's standard record locking—user X has activated the Edit process, and no one else can open this record until user X activates the Update process.

Nevertheless, these are good issues to consider. Your clients might just ask for the ability to rename the file when saving and see the new file name in FileMaker. This could be done, but only if you set up a widget that lists the contents of the temporary folder. This can be done via either system script or plug in.

The major negative here is that no matter how you slice this, there's some extra "user education" that has to take place or the users might edit a document, save the changes and then lose them when they fail to insert the modified file back into the solution.

This is something that I've been aware of ever since external storage became an option in our solutions. I like the added security and the fact that you don't have to make the external storage location directly accessible to the user like you do with "by reference", but you lose that ability to just open in default application, save changes and be done with it, that can be done when you open the file directly via double click on a "by reference" file in a container field, go to field on the same or by using Open URL.

Hence my speculating on the idea that you open files in a given folder (not necessarily temporary folder), and use a plug in or system script to monitor what files exist in the folder, re-inserting, then deleting any files found there as a way to ensure that changes made to the documents are not lost from your solution managed copies of the same.