I'm getting an Error 500 when loading SCSetBaseURL. What would cause this?

I'm using 2.2 on Mac OSX 10.5.8 with FMS 9.

Edited November 18, 200916 yr by Guest

Is "Error 500" the error message you are receiving when you call SCLastError after calling the the SCSetBaseURL function? Error 500 is a common permissions error on mac, but it is usually seen when trying to upload a file and SuperContianer does not have write permissions to the SuperContainer directory. Are you also calling SCSetContainer in the same script?

Could you please post your SuperContainer Companion plugin log? Logs can be found at:

/Users/userName/Library/Logs/360Plugin Logs/

or you can use the "Report a bug" feature in the preference>plugins>configuration screen to email your log to us.

I would also recommend updating to the latest version of SuperContainer. You can download the latest version from http://360works.com/supercontainer/

I sent an e-mail to Sam before I saw this post. Don't know if it's better to continue via e-mail or forum...but here it goes.

It is definitely being caused by SetBaseURL. I didn't realize at first that SCLastError behaves differently than Get(LastError) in that the error persists throughout the script (indeed it is only cleared when FMP restarts), but I error checked the script the whole way through and the only other SC function that is called is SCVersion, and that does not produce an error.

The errors in SC Server window are:

An error occurred while handling request /SuperContainer/Files

java.lang.NullPointException

An error occurred while handling request /SuperContainer/Files/?md5=false

java.lang.NullPointException

Logs attached...

SC_LOG.txt

Console.txt

These logs are not showing your error, unfortunately. Could you please call me at 770-234-9293 and we can set up screen sharing so that I will be able to take a look at you system and you can show me this error?

I called David and he had me up and running in 15 minutes.

360Works has excellent support!

Care to share your wisdom?, or was the advice you received specific to your setup.

I ask because I too am receiving a similar error.

Is it a permissions issue somewhere?

from the log

1/20/10 3:06:12 PM - An error occurred while handling request /SuperContainer/RawData//floorplans/6?width=740&height=350&doNotDownloadNonImage=true

Could not initialize class com.prosc.supercontainer.model.ImageResizer

error showing

My advice is to call SuperContainer support.

99.9% of the time an "Error 500" message is a permissions issue. You will need to make sure that your SuperContainer server has read and write access to your SuperContainer server and all subdirectories. This is most often an issue when the SuperContainer folder is copied from another computer.

There can be permissions issues when two accounts with the same name exist on two machines, and a folder is copied from one to another. Even though it may say "read & write" you may not actually be granting the correct permissions. It is recommended that you download SuperContainer directly from our servers to the machine that you will be installing it on.

Also, make sure that you are running as an administrator on your machine, and that you are not telling SuperContianer to save files to a directory that already exists, as doing so can cause permissions issues as well if the folder was not created with the proper permission sets.

It also looks like you have some strange and invalid url parameters:

&am p;height=350&doNotDownloadNonImage=true

an ampersand is fine (and necessary)to include in your url, though it looks like you tried to add an encoded one as well which also has a space in it. You can just put in an ampersand, and do not need to encode it in any way. The semicolon may be throwing off the URL as well.

Also, doNotDownloadNonImage=true is not a valid SuperContainer URL parameter, and I would recommend removing it from your URL.

These may be related to your error 500, as SuperContainer may be trying to write to some invalid directory because of these strange parameters.

Thanks, thought I had checked the permissions , but I reset them any way ( for everything in the supercontainer folder within the user/shared directory)

Also realized I wasn't running the newest version (doh!). Upgrading and fixing the permissions did the trick!- thanks

re: the problem with &, my code was good, the encoding must have happened during a copy and paste function!

Trying to install the demo on a weekend is such fun. I had the same error, and finally fixed when a stop/start of the server revealed that I had moved the folder the jar file was unzipped to. Now I have a coffee cup with an !. Progress!

The coffee cup with ! means that there is java conflict somewhere, most likely from an out-of-date plugin. You can test this by removing all plugins from your FileMaker and trying it again. Check in your Filemaker > Preferences to see which plugins are enabled, not just your extensions directory as you may have plugins installed in your auto-update directory as well as your regular filemaker directory.

I'm also getting a 500 error.

I have a production system with a Job table.

From here I use ScriptMaster to create folders on the file server for each new Job.

I then want to use SuperContainer to write into these folders when required.

It is here when I get the error.

Graphic artists also need to access these folders directly.

Any suggestions how to fix this?

My understanding, having been through something similar, is the SuperContainer needs its own write permissions because if you go messing around with files then you cant expect them to be there when you want to recover them, so as far as possible you dont get to see the directory structure.

Surely what you are after could be achieved by using some Scriptmaster functions to create directories and manipulate files to them.

The same issue as before, "Error 500" is a permissions error, which means that SuperContainer does not have read or write permission to the directory you are uploading or downloading files from. This will happen if you have users or other processes accessing your supercontainer root directory on your server and uploading files through that.

You should never read or write files directly from or to the SuperContainer structure on your server. SuperContainer is a replacement and upgrade for a regular container field, and like a container field the files you store in it should be accessed through FileMaker, even though they are technically available outside of filemaker. Accessing, adding, and deleting files outside of filemaker will cause problems in your filemaker database and make SuperContainer and your filemaker users unable to access files stored in SuperContainer.