You could sidestep the problem. Save the original in the global field before export. Always ask if they want to Update or Ignore Changes. Set the script to save either the new file or the global field saved version back into the ‘real' field depending on the user choice.
2 of 2 people found this helpful
Use the GetContainerAttributes Function to get the MD5 Hash value for each container field and compare the values. If the data in the field is the same, the mdb value will also be the same.
I fear this will always give me a positive, as the comparison file is new, it is a temp made from exporting. Let me try it.
This is already covered, what I am trying to avoid is not ask if the file wasn't edited.
You can compare two containers simply as
containerField = globalField
(tested on FM15 Windows7, using internal storage, embed)
(Actually, in my suggested scenario you don't need the global field. If the user chooses 'Don't Update' just do nothing and leave the original file.)
I believe there are pluginsthat let you get the modification timestamp of a file. That might work for you. Seems (proportionally) a lot of effort, though.
The problem is GetContainerAttribute( globalField ; "fileSize" ) is always different from GetContainerAttribute( containerField ; "fileSize" ) because the file was made recently and has a different byte size.
Did this really occur on mac?
On windows, file has 2 sizes that file size and size on disk. The function returns file size, so when export field contents, size on disk can be different but the file size is equal to original size always.
What happens if the user modifies the file and coincidentally the end file is the same size as the start file?
I'd still lean towards asking for confirmation every time. Better once too often than once too seldom.
philmodjunk is correct. Use the following function to compare two container fields to see if the contents are the same or different:
GetContainerAttribute ( sourceField ; "MD5" )
This gives you a checksum for each file that will change if the file contents change. It is not affected by the modification time, file size attribute (which is actually a kind of rough number), but only if the contents of the file change. I've used this successfully for exactly the situation you are describing, and it works as expected.
I'm really glad FileMaker made this available to us. When they added storing external remote containers with the 'secure' option, they used this to show the error message if the files change outside of FileMaker, but they didn't have to give us the same ability.
-- Drew Tenenholz
Thank you philmodjunk, this solution worked quite well.