Qdabra qRules

Re: ExecuteSQLQuery and browser compatibility

tenbao — Sun, 09 Sep 2012 03:17:07 GMT

Yes , that's exactly what I did. It is an awesome thing to see as a non-programmer . :-)

Re: ExecuteSQLQuery and browser compatibility

ErnestoM — Wed, 05 Sep 2012 14:21:29 GMT

Hi tenbao-

In our test scenario, we got this to work in the browser by converting the data connection to UDC and admin-approving the form.

Does this match your scenario?

We'll update the user guide to clear this up. Thanks for pointing out the issue.

Re: ExecuteSQLQuery and browser compatibility

Patrick Halstead — Sat, 01 Sep 2012 18:32:35 GMT

Hi Tenbao and thank you for your qRules forum question,

The browser doesn't forward credentials to SQL; you might be able to hardcode the credentials in a UDC file - I would try that if the DB is on the same ShP server; there might also be a way to use SSO to use a fixed set of credentials to connect to it. We haven't tested these methods, but in theory they should work. However, I will ask support to update page 59 to be consistent with the earlier "non browser compatible" comment.

I will also ask Hilary and others to test the UDC hacks and if those work, we'll document how to do it, but I think we'd still say it is non-browser. That's because the credentials will be fixed which means there will be no dynamic SQL permissions which isn't a best practice for security reasons.

The best practice when you have a browser form and a SQL database is to use a Web service which forwards the credentials of the user. Qdabra's DBXL Web service does this. It's also a cost saving to you since you can use just one Web service for all of your InfoPath form templates. In other words, you don't have to create separate web services for each XSN. You just specify a new mapping. This loosely coupled architecture is possible because InfoPath always validates XML before it is submitted - so we know the XML will be structurally and data-type valid. That means the Web service doesn't have to validate the data before submitting to SQL. Which means the mapping can be loosely coupled. This loosely coupled architecture is a huge boon for business processes since form updates do not have to stop the submit process. For updates that change the XSN data source, you can simply publish a new document type and specify a mapping that maps to the same SQL tables as the previous version. In this way, you can smoothly transition from one version to the next without stopping the submit process. I.e. less maintenance cost and much lower impact to users submitting forms.

If you can install a Web service in your environment, please give DBXL a go. We have a free trial on our sister site - Qdabra.com. The trial is good until September 15th, but we can extend you if you a month or two - just send us email.

Thanks,

Patrick

ExecuteSQLQuery and browser compatibility

tenbao — Fri, 31 Aug 2012 21:47:04 GMT

Please ignore this post. I did not force a field which had a rule to query a data source to return data to the server. Once I did this, the ExecuteSQLQuery command ran

-------------------------------------------------------

In the qRules User Guide, the PDF mentions that the ExecuteSQLQuery command is not browser compatible. But then on page 59 of 74, the table marks it as Browser compatible. Which is it? I haven't been able to use that command to return SQL data in the browser.

qRules User Guide found here: http://www.infopathdev.com/files/folders/qrules/entry34834.aspx