You could do that or when you move from dev to production open the form, right click on the data connection, look at its properties and update the WSDL address. Now save your form and it will go against the prod environment.
in a table in our database, it stores the server IP. in the development database, it stores development server's IP; in the production database, it stores production server's IP.
so, I thought I could make a query at the Render form service, and get that IP and put it in a hidden field on the form. Then, at the time the form is loaded, I can use a line of script to set the soapAddress like this:
That technique is OK ...what event do you have the script on? Put it on a button so you can see the execution and ensure that IPField is filled. Once you know the code is good put it on the Form Ready event.
Also make the target version of the form something less than 8.0 or else it will not allow you to change that setting (File/Form Properties/Defaults).
Setting the soap address is no problem ....executing it is the issue. If you run it server side you should it will react the sam eway whether it is Acrobat or Reader. All I am saying is that to execute the web service client side in Reader you need Reader Extensions.
as I said, I don't have Reader Extensions, I can't Reader-extend my form.
does that line of code work for you if you don't Reader-extend the form?
setting the SOAP address is a problem for me in an environment that does NOT have Reader Extensions.
Am I understanding you correctly, that this technique can only work after the form is Reader Extended???
If so, is there another way to make it work for a form that's not Reader-extended?
to answer your question:
I have some other lines of script after that soapAddress line, and those lines of scripts never got executed, the execution terminated at the soapAddress line. and I didn't get any error message, it just terminated.
The line of code does not work if you do not have Reader extensions and here is why.
When you create a soap connection the information for that connection is stored in the DOM under connectionSet. If you run this in Reader it will not allow you to create a conectionSet (unless you Reader Extend). So the script is failing because connectionSet does not exist and the failure halts execution of the script. So...the Reader extensions does not allow the script to run but it allows the creation of the connectionSet which in turn is referenced by your script.
There is no other way to make a client side soap call without Reader Extending.
In summary, the Reader Extensions is for the ability to allow Soap to run not to allow your scripts to execute.