charles huff Posted October 26, 2010 Posted October 26, 2010 (edited) Filemaker is caching supercontainer filed pdf's (or scribe) somehow. Drop pdf into SuperContainer webviewer, file uploads, click extract and data is populated into filemaker fields. Change pdf, drop again to overwrite, data is on server verified, but click extract and the old data is pushed into the fields again. quit filemaker, go back and do just the extract script and new data is written to filemaker, even when I skip the upload step via the webviewer... How to make Filemaker flush the cache??? Close reopen file won't work. only quit filemaker does it. Edited October 26, 2010 by Guest
charles huff Posted October 26, 2010 Author Posted October 26, 2010 (edited) SC ver 2.76 - Scribe v 1.115 - fmp 11.2 - java for mac 10.6 update 3... it seems the drag and drop feature works only once per filemaker session. This may be the underlying problem... Downgrade to Scribe v 1.02 did not help...also the sequence of upload, extract data, delete file, extract data fails to change any data until the fmp client is restarted. Edited October 26, 2010 by Guest
charles huff Posted October 26, 2010 Author Posted October 26, 2010 The work around I have found is to make a regular container field.ScribeDocLoad("http://xx.xxx.xx.xx/SuperContainer/RawData/Rights/" & Timesheets::__Serial & "/" & Get(AccountName) & "/" & Year(Get(CurrentDate)) ) will fail as noted above. BUT, SCGetContainer( "Rights/" & Timesheets::__Serial & "/" & Get(AccountName) & "/" & Year(Get(CurrentDate))) and ScribeDocLoad(Timesheets::RightsDocument) WORKS! it just takes longer to complete....
Smef Posted October 26, 2010 Posted October 26, 2010 Are you saying that the drag-and-drop to SuperContainer is only working once per session? I'm using the same FileMaker, SuperContainer, Scribe, and Java as you and am not currently able to reproduce this issue. Would you mind contacting me to do screen sharing? Are you using the Java applet or noapplet mode? You cannot drag and drop files in noapplet mode. If you try to do this your files will not be uploaded to supercontainer. Instead, your web viewer will be pointed to the file on your local system (this is filemaker's web viewer behavior). You cannot work on the file directly on your SuperConainer server. If you try to run scribedocload on the SuperConainer server URL you will download the file to your cache and be working on it from there, not on the server. When you save the file it will be saving in your temp directory on your local computer. You need to store the file in a temporary container in your database, work on it, save it, and then re-upload it to SuperConatiner. It looks like this is what you figured out to do in your last post. Let me know if there are any more questions you have.
Steverino Posted January 14, 2011 Posted January 14, 2011 David, I'm having the same problem. I'm bouncing between SuperContainer Server on a server and on the local computer, synchronizing images sometimes one way, sometimes another. Here's what I find: if I upload a new image and then sync it, everything is fine. Change that image in one file and then upload to the other file/computer, and the old image is still appearing...until I restart FM. Flush cache doesn't appear to do anything. Any suggestions? We can't keep restarting FM. Are you saying that the drag-and-drop to SuperContainer is only working once per session? I'm using the same FileMaker, SuperContainer, Scribe, and Java as you and am not currently able to reproduce this issue. Would you mind contacting me to do screen sharing? Are you using the Java applet or noapplet mode? You cannot drag and drop files in noapplet mode. If you try to do this your files will not be uploaded to supercontainer. Instead, your web viewer will be pointed to the file on your local system (this is filemaker's web viewer behavior). You cannot work on the file directly on your SuperConainer server. If you try to run scribedocload on the SuperConainer server URL you will download the file to your cache and be working on it from there, not on the server. When you save the file it will be saving in your temp directory on your local computer. You need to store the file in a temporary container in your database, work on it, save it, and then re-upload it to SuperConatiner. It looks like this is what you figured out to do in your last post. Let me know if there are any more questions you have.
Smef Posted January 18, 2011 Posted January 18, 2011 There should be no synchronization that you need to do, and i'm not sure what you mean by you are syncing in different ways. When you upload a new file to SuperContainer you will not see the new file uploaded on another machine until the web viewer is reloaded. This can happen by changing records, layouts, or by calling a script step to reload the web viewer. Are you modifying the file and saving it, or are you actually re-uploading the file? If you are modifying it you are only modifying the cached file in your temp directory. You need to actually save the file to your computer, modify it, save it, and then re-upload it to SuperContainer. Saving a file does not automatically re-upload the file to your SuperContainer server. You should not be uploading files to different computers, if that's what you're doing. You should only upload files to your SuperConainer server, of which there should be only one deployment of. Are you running multiple instances of SuperContainer Server? There should be only one deployment of it and everyone should connect to the single deployment, like you have only one deployment of FileMaker server which all of your users connect to. Please give me a call and we can discuss this on the phone or on Skype.
Recommended Posts
This topic is 5059 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now