InfoPath Dev

Ernesto, /my:funding/my:qdxtp_historicalFunding/my:Content/my:historicalFunding[my:amount != ""] did not work. It prevented all child records from being created (when the user later updates the form and enters in child records).

FYI, the complete Node Path for the coditional mapping is: /my:historicalFunding[/my:funding/my:qdxtp_historicalFunding/my:Content/my:historicalFunding/my:amount != ""]

Ernesto, I've tried a conditional mapping and it did not work. I expect I am not using the correct XPath to the field "amount". (The field is required from a business perspective but not, yet, required by the form.) See the attached image.

The "Submit data to DBXL from a non-InfoPath form" document Ernesto provided a link to will be very helpful for our .NET developers if/when they begin to use the DBXL service. This document provides more information than I've seen from other vendors of web services. In my experience, while it is easy to say the ...

I will have to provide the capability for third party systems (e.g. not InfoPath or SharePoint) to submit data to the DBXL web service. A specific scenario is having our SAS business analytics system submit information (forms) to DBXL. While the DBXL web service documentation (QdabraWebService/dbxldocumentservice.asmx) is relatively ...

There was a problem with the Active Directory group being used. It was recreated in AD and DBXL is working fine. Jim, thanks for the troubleshooting suggestions.

I have an XML-to-XML solution that Ernesto assisted with the creation of. It is likely an unique business case- the target document type fields are not entered by users when the host document type form is initially created and submitted. It is not until an existing host form/record is edited by users that they enter data into the target ...

Update: The forms were set with a security level of Full Trust and published as Administrator-approved form templates. I changed the security level to Automatic (with the Domain level radio button appearing selected while also grayed out) and the error did not reoccur. I first did this for one of the forms, verifying that it continued to work ...

Ernesto, You are correct. The SQL Server Import and Export Wizard did not maintain the Primary Key and (Is Identitiy) setting for the ID column when I migrated the database. FYI, after making the database changes I did have to exit the the document type settings in DAAT (going back to the catalog) and then went back in to the document type ...

Update: 1. I republished one of the forms and the problem remains. 2. After rebooting the servers yesterday, the problem returned today. 3. Performing an iisreset /noforce on the web front end server corrects the problem until it returns again.