SCninja

Printing web portals is a very delicate subject ( regardless of whether you're utilizing SuperContainer or not), in that FileMaker literally has NO idea of when each web portal has completely loaded its content before queuing it for print. The simplest way to curtail this is to use unstored container fields that point to the file on your SuperContainer server. What this does is force FileMaker to load the container field before trying to print the page. Signed,

Honestly, I would be surprised if Jesse was not still contributing to the development/upkeep of SuperContainer. SuperContainer still offers some delicious features ( the first that comes to mind is the ability to easily upload data via the web, deploy in multiple locations, and a PHP API to use outside of FM ) that FileMaker container fields do not. Personally, and I'm sure for other users who need some or all of these additional features, believe that SuperContainer is still a viable container storage utility. Signed,

As is the implication from John, all 360Works products require a 32-bit installation of Java. Signed,

Hey there, I am going to assume a few things from your last post: 1. You're using the RawData protocol in the SCSetBaseUrl() Companion plugin function somewhere. 2. You've discovered that you need to use the RawData protocol instead of the usual Files/ for one reason or another in your solution. Now, to quickly tackle these: 1. There's never a time you will need/should use the RawData/ protocol when setting the base URL. Put simply, replacing the RawData with Files/ in your plugin function call should remedy your error messages. 2. More often than not, the only places you'll have use of the RawData/ protocol are in web viewers... otherwise, it's better and cleaner to just stick to Files/ (I may be forgetting a place or two, but WV is most common). I hope this helps clear things up. Signed,

I've deployed SC on my Mac OS X machine running FMS 11 with Java 7 and didn't have any major issues. However, I'd look to the 360works folks for a more definitive and inclusive answer on Java 7 compatibility. Signed,

Yes. As stated on the licensing page, the license is per server deployment. So if you have one machine running FMS10 and another running FMS12, you will need two separate licenses for each machine. Signed,

Yes, The folks at 360Works provided three different deployment options for this very reason. So, in your case you can simply deploy SuperContainer server on your Windows machine using a custom install of Tomcat. By default you will be using port 8080 to access SuperContainer (i.e 127.0.0.1:8080/SuperContainer), but that can be changed with proper knowledge of Tomcat configurations. In fact, 360Works provides some pretty good documentation on their product wiki page that explains how to configure different ports when using SC with Tomcat. Signed,

Hey there, There could be a number of things in play here: 1. First off, I would recommend avoiding the use of file names as your SuperContainer folder path. Instead of: /All Scans/3211-Registration.jpg Use: /All Scans/1 with the file 3211-Registration.jpg uploaded to that SC folder. 2. Are you running the latest version of BOTH SuperContainer server and the Companion plugin? This is critical to ensuring uploads, downloads, and deletions work. 3. Did you set your base URL to the correct machine containing the file to delete? This is probably a no-brainer, but you'd be surprised at how many instances I've seen this occur. - Make sure if you're running the server on port 8020, you've set your base URL to this as well. Signed,

I would first check to make sure you're running the latest version of BOTH SuperContainer server and the Companion plugin.... I have seen this behavior once or twice before (in a Windows server environment). Anyway, definitely upgrade if you aren't already running version 2.864. The next thing I would take a look at is to make sure you're getting the email attachment alright and can view it successfully. If these two are checked out and look good, I would just give 360Works tech support a call. EDIT: P.S Also! If you are in fact in a Windows environment and running SC via FMS' WPE, I would try a different deployment method as a temporary workaround (e.g Tomat deployment or standalone). Signed,

This error usually displays if you are running conflicting/older versions of the SuperContainer product. Please ensure you are running the latest version of BOTH SuperContainer server and the Companion plugin -- if doing plugin uploads. Regards,

Well, with iOS6 it is now technically possible to perform uploads with SuperContainer. I believe it is only a matter of time before the gents at 360Works implement this feature and it's released publicly. Regards,

As mentioned briefly by Ocean West, Docubin sounds like a viable solution in your case. I would definitely give 360Works' Docubin a look as it implements the features you're looking to take advantage of. It is truly a complete Document Management solution built in FileMaker (with tons of neat tricks and added bonuses). 1. Drag and Drop functionality 2. User permissions 3. Search features and a lot more... Signed,

Hey Todd/Tony, Are you running FMS on a Windows or Mac OS X machine? Just so I can try to better reproduce this on my end. Signed,

Hey Tim, There is actually a way to increase/reduce the logging level of the log files being created by the 360Works plug-ins. You will need to edit the logging.properties file by adding something similar to: com.prosc.beanshell.level = SEVERE (where com.prosc.beanshell is the Java package for ScriptMaster) at the bottom of the properties file. The above would limit the logged messages to the SEVERE level, which would reduce your log file by displaying only the errors that are marked as severe. The default location of the logging.properties file is located at: I hope this helps. Signed,

Guy, What version of SuperContainer server do you have installed? Make sure you're running the latest versions (2.864) on both the server AND the Companion Plug-in. This seems the most likely cause. Signed,