Stephen Hill

I have not setup my test servers yet, but until someone with greater detail jumps in: * Only one active server, yes. The second server should only receive interaction from the primary until activated in a failover. * There are quite a few solutions for handling the failover with IP access. A couple of the ones we've used are below, they're easy to setup but you can take extra steps if you want it to work a bit different. - a DNS service that supports failover changes -- when the failure is detected, you'll have to tell the standby to go live and poke the DNS so that it provides the stan

Both solutions work perfectly fine when opened alone after a fresh start of filemaker. The implementations do not produce those auth errors. A second (or third, fourth, fifth) database accessing the same subdomain+domain works fine as well. The problem occurs when you attempt to use two solutions opened in the same filemaker instance each accessing a different subdomain (possibly full domain, but I haven't tested that.) The username/passwords are correct for the supercontainer, and work fine, the authentication problem results from failing to actually send the correct data (username at

If I open one database, and it's: INFO: Setting supercontainer base url to https://url.domain.com:443/SuperContainer/Files And then I open a second database, and it's: INFO: Setting supercontainer base url to https://url2.domain.com:443/SuperContainer/Files I get the following when running SCGetInfo( ... ; "md5" ): Apr 30, 2011 1:50:23 PM org.apache.commons.httpclient.HttpMethodDirector authenticateHost WARNING: Required credentials not available for BASIC <any realm>@url2.domain.com:443 Apr 30, 2011 1:50:23 PM org.apache.commons.httpclient.HttpMethodDirector auth

I'm not asking for you to do anything about this portion off the problem, unless you have a method for checking if a file is open within one of the 360works products. This is the 'minor' error that may be producing a condition that results in the 'major' followup error which results in supercontainer companion plugin ceasing to work at all in uploads and downloads. I posted here to see if 360works had any information regarding the 'couldn't create component peer' portion, and noted that I've only seen it show up so far after the 'already open' error has occurred. I can not eliminate all

This is exactly the problem, and yes, so far it appears that without this error, the nastier component peer followup error does not occur. The problem is that, as far as I can tell, I have no way to check if the file is currently *open* (and cannot be used to save a new file to.) Is there a function for this? What is occurring is a user activity. They're clicking the button which runs the script which downloads the file, and then sends the event for the file to open. Some of the users appear to become impatient with their machines, or through activity click into another applicatio

This has been an elusive problem a client has been having that I could not reproduce until just recently. Under certain client conditions, eventually all 'SCDownload' (and upload at least, I have not tested enough else yet) will eventually result in nothing but "java.lang.InternalError: couldn't create component peer" and this cannot be fixed without quitting the filemaker application, and starting it fresh. This occurs on all databases opened, even with all closed and re-opened, the application must be exited. I have been testing for this for months, without any success, until testing

Ok, I've worked it out to be a more general problem. I'm using a MS Word document with multiple control elements, including several checkbox controls. The script is rocessing through the ScribeDocListFields, and only doing a ScribeDocWriteValue for the elements that have matches in the database. I have confirmed that the following sequence does not result in this error: 1) ScribeDocLoad 2) ScribeDocListFields 3) ScribeDocSaveFile However, if I do a *single* ScribeDocWriteValue to any element, and then DocSaveFile, every single checkbox control element reverts to a plain

It's nothing special that requires a document. Any data placed into a checkbox control element seems to eliminate the 'checkbox' user functionality. For my part I've just resorted to drop-down lists instead, assuming it's something unusual in the way word checkbox elements are implemented. It would just be nice if there was a way to populate the checkbox control elements.

The Get( ...Path ) Filemaker functions return "/C:/dir1/dir2/dir3/" If you do not remove the leading "/" before C:/... the ScribeDocSaveFile prepends the temp directory (thus the weird double path you're getting.) The "file:" should not be necessary for this function call.

I'm using a .docx document with control elements, populating the fields just fine in bulk, things are working well. The issue I'm having trouble with is the checkbox control elements, which appear to be RTF control elements with some special checkbox behaviour that appears to possibly be based on active elements from within word. I've experimented a bit, and while I can certainly put my own text in to get it to show boxes or not, doing so eliminates the checkbox action on the control element, it drops to just a plain RTF element. Is there any known way to 'insert' the checked or notche

I apologize for failing to get back to you in a timely fashion. It was not done as an intentional expression, this month has just kept getting busier and I shelved this issue to finish some priority work. I am quite happy to say that the 24 jan 2011 updates for fixing auto update have solved this issue for me, thank you so very much.

I am getting frustrated with these responses, as I feel that they do not reflect an understanding of the problem. Yes, I have tried from your server. Yes, it doesn't matter, the point of acquisition of the updated file is not part of the problem (your server or mine, the download of the new version is always successful) -- it is the state of the currently installed plug-in that is breaking the process. This addon (supercontainer companion), and other 360works addons, have become incapable of being moved (which is required by the FMSAUC process), even with no database having been op