When troubleshooting issues on a server where DBXL is installed, DO NOT stop the SharePoint Foundation Web Application service. Stopping this service will remove the IIS sites from the server.  Starting the service recreates the site, but the DBXL install will be lost. Here's a screenshot showing the service in SharePoint Central Administration.

If this should happen to you, you'll find that DBXL is still listed in Control Panel > Program, but nowhere to be found in IIS or in the folder structure. If you try to install or remove DBXL, you'll run into this error:

To resole this,

1. Go to the registry editor and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products.

2. Within this location, use the Find operation to locate Qdabra (DBXL).

For example: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\A8E1F369782E6534894469E36122F2D3

3. Delete this key.

4. Reinstall DBXL using the existing databases.

Thankfully, this process re-uses the databases, which means your document types and documents are all retained.

Over the years we've noticed that SharePoint updates may sometimes interfere with DBXL. Typically, correcting the DBXL App Pool identity and/or performing an iisreset fixes the issue.

We've noticed, however, that even adding a new web application in SharePoint Central Admin will cause SharePoint to change the DBXL App Pool to the SharePoint App Pool. When you try to access DBXL afterwards, you'll get an error!

Here are some screenshots illustrating the issue.

1. Before starting, we notice that the Dbxl App Pool has one application.

2. Then we add a new web app in SharePoint Central Admin.

3. Afterwards, the Dbxl App Pool has no applications!

To fix this, update the QdabraWebService to use the Dbxl App Pool once again, and DBXL will return to its previous, working state.

If you have questions or encounter similar issues, please contact Qdabra Support.

In many DBXL documents published by Qdabra Software, we add a data connection to the SubmitDocument method in the DBXLDocumentService. It should be noted that this web service will not return errors to the user. This means that if the submit should fail, users won't see an error message. And if the form is set to close after submit, the form will close and the data will be lost.

How can this be addressed? There are two main options:

1. You could use the DBXLDocumentServiceEx web service instead. This web service is the SAME as DBXLDocumentService, except that it will return error messages.
2. You could submit using the qRules command called SubmitToDbxl. The added benefit of this command is that it returns the new document's DocID, should you need it for anything within the form.

Of course, if an error is returned in either scenario, you'll want your form to NOT close, thus you avoid losing the user's data should the submit fail. For example, in the qRules scenario, your rule would be conditioned on SUCCESS=true(). If that condition is satisfied, then the form can be closed safely.

Showing error messages to users is risky since it can confuse users and interrupt their work. With some testing of the solution, you'll be able to address any potential issues before the form is launched to a production environment. For errors that slip through the cracks these two methods should catch them.

For a step by step description on how to submit to DBXL using qRules, please see this document:
http://www.infopathdev.com/files/folders/qrules/entry35303.aspx

For an example on how to use the DBXLDocumentServiceEx.asmx web service, please see this previous blog post:
http://www.infopathdev.com/blogs/jo-anne_alfafara/archive/2009/05/15/how-to-report-shredding-errors-to-form-users.aspx

If you have questions about either method above, please contact suppport (at) Qdabra (dot) com.

In the past we have shown how to create a SharePoint data view to show the data stored in DBXL. Here are some references:

1. Create a SharePoint 2010 Data View that uses GetListItems to access DBXL forms
2. Create a SharePoint Data View that uses GetListItems to access DBXL forms

These steps involve using SharePoint Designer 2007 or 2010. In SharePoint Designer 2013, the WYSIWYG editor is no longer available, which makes the process of creating a data view more difficult.

Using the QueryDocumentNodeSet web method, contained in the DBXL web service, we can create a codeless, browser compatible InfoPath form which acts as a data view or a Dashboard.

The package includes:

• Step by step instructions
• InfoPathDashboard-QdExpenseReport.XSN which is the Dashboard for the Expense Report doctype that comes with DBXL.
• InfoPathDashboard-CustomerContact.XSN is the Dashboard after following the steps to reconfigure it to query from the CustomerContactForm.XSN (that form template is also attached).

Click here to download the package.

This tutorial allows you to create an InfoPath template part (XTP) that will lock and unlock forms that are stored in DBXL. You can reuse this XTP in any form template where you wish to provide this functionality to your users.

Please click here to obtain the PDF tutorial.

Qdabra Software recently was faced with an error when creating a SharePoint Designer workflow. When sending an email, if you insert a variable into the body of the email, it fails to save or publish the workflow.

For example, if you add the following to the email body:

Then the following error comes up when trying to publish the workflow. 

If the variable is removed from the email’s body, there is no problem publishing the workflow.

Qdabra found a workaround for this:

1)      Create a string workflow variable. I called mine BlankString.

2)      After entering the variables in the email body, open the Properties tab for the email step.

3)      Click on the Body textbox and then click the ...

4)      Place the cursor after the text </HTML>.

5)      Click on Add or Change Lookup and insert the empty string variable.

6)      Click OK and publish the workflow.

This simple change will allow you to publish the workflow without issues.

Let's pretend that you've been using a SharePoint Form Library and you have hundreds of documents (XMLs) already submitted. You found out about DBXL, purchased it and now want to make the full switch.

Here are some general guidelines to help you with the migration.

1.    Edit the form template to add a DBXL submit. (You will find information on this in the Getting Started document.) Because you are now submitting to DBXL, you will no longer need to submit to SharePoint directly. DBXL will handle that.

2.    Create a DBXL document type. (Again, you will find information on this in the Getting Started document.)

3.    Add a SharePoint mapping to a new form library. (That way we keep the original library as a temporary backup in case we need to revert.) For information on creating this SharePoint mapping, see this document.

4.    Use SharePoint's Explorer view to copy the XML files from the existing form library to a local folder.

5.    Import the XMLs into your document type using the Import web service. This can be done in two ways.

a.    Via Internet Explorer on the server where DBXL was installed. Simply navigate to https://training.formsboard.com/QdabraWebService/DbxlImportExport.asmx?op=ImportDocuments to use the Import web service. You will need to provide the name of the document type you created (in step 2) and the path where the XMLs were stored (in step 4)

b.    Via the DBXL Admin Tool, in the Documents tab. However, note that this method will fail with a timeout, depending on the number of the documents to be imported.

We've recently seen some questions about the SubmitToSharePointList command in qRules. One common error is:

Security Exception - please check security requirements for this command.

There are two solutions for this issue:

1. Set useWebServices node to true. You can do this by adding an action (before the SubmitToSharePointList action) that sets the useWebServices node to true().
   
2. Make the form Full Trust. You can change this in Form Options.
   

Imagine that your InfoPath form, which submits to DBXL, needs to make sure that there are no duplicate records. Using the web method QueryDocumentNodeSet, we can quickly check whether DBXL already contains a matching record.

For the purposes of this tutorial, we will implement the solution on a very simple form, though you can extend this as desired. You can download the PDF tutorial (13 pages, 950Kb) by clicking here.

DBXL versioning is turned on by default, as it is necessary for certain scenarios. For safety purposes the checkbox in DAT is also disabled, so that it is not accidentally deactivated. (For a PDF version of this blog post, click here.)
 
However, should you wish to turn off versioning (i.e. uncheck Enable History), follow these steps:

Export

1.    Download and install the DBXL Migration Tool.
2.    Launch the DBXL Migration Tool (UI).
3.    Enter the DBXL Server Root and click Connect.
4.    From the Configuration dropdown, select your document type.
5.    Check the checkbox for Configuration under Items to Export.
6.    Enter an Export Path.
7.    Click Run.

Manually modify the mapping.xml file

8.    Open the mapping.xml created by the DBXL Migration Tool in the Export path. You can use Notepad or a similar text editor.
9.    Find <HistoryFlg>true</HistoryFlg>
10.    Change this to <HistoryFlg>false</HistoryFlg>
11.    Save and close mapping.xml.

Import

12.    Back in the DBXL Migration Tool UI, switch to the Import tab.
13.    Click Load next to Configuration.
14.    Select the document type from the Configuration dropdown.
15.    Under Items to import, check Configuration. Note: If you had a SQL Mapping configured, you’ll need to enter a value for Database server and Initial Catalog. These will match the Connection string in DAT.
16.    Click Run.

When you go back into the DBXL Administration Tool, you’ll see that the checkbox for Enable History is unchecked!

During Qdabra’s free weekly webinar on November 10, 2011, we discussed three possible contact selectors, their pros and their cons. This follow up blog post will summarize that webinar and provide you with XTP and XSN samples. You can download the supporting files here.

One of the main concerns when using a contact selector is that it should be reusable. After all, you probably will need similar functionality in more than one form. Save time by creating an InfoPath Template Part (XTP) and simply injecting it into your InfoPath form template (XSN)!

People picker

Microsoft provides users with one such reusable contact selector. It’s called the People Picker and it’s available, out of the box, in InfoPath 2010.

This is definitely one advantage: it comes with InfoPath, so there’s nothing to set up, and it will connect with your SharePoint server to find users.

The disadvantage is that the schema is locked. When you add this control to your form, you’ll see that the nodes have a small padlock next to them, meaning that you cannot modify them. You also cannot add more fields under the repeating node (/my:myFields/my:group/pc:Person).

You can perform some configuration on the control, such as allowing more than one user, but it’s not highly customizable.

The control is browser compatible, and the sample form that we include in this package is as well. Simply publish the form to your SharePoint server to test it.

Qdabra’s non-Active Directory Contact Selector XTP

Going one step further we come to a contact selector that still obtains user info from SharePoint, but this one offers more flexibility. Notice that the schema is not locked, meaning that we can modify it as desired.

The XTP uses a connection to SharePoint’s UserProfileService to obtain the user’s info.

But this XTP also has its own drawbacks, namely: you’ll need to search for user's EXACT alias (there is no option for partial matches). In addition, there is no option to list all users. You search for a users alias, and select that user. In the example provided, we are also retrieving the user’s email address.

This XTP uses qRules for some actions, though it would be entirely possible to build a simpler non-Active Directory XTP, without qRules. Therefore, the XSN included in this package is injected with a trial version of qRules. If you have purchased the qRules, you can reinject the XSN with the full version.

The XTP is included in the downloadable package. To use it:
1.    Create a new XSN form template and save it.
2.    Inject your XSN with qRules.
3.    Add the XTP to your Controls, and then insert the XTP your canvas.

Once the XTP is on your canvas, you’ll see some configuration steps you’ll need to follow.


Qdabra’s ContactSelector XTP

The previous two XTPs did not query Active Directory, but Qdabra’s Contact Selector XTP does. Why Active Directory? The Active Directory web service allows us to list all users as well as search for partial matches, and the results provided by this web service contain a wealth of information about the users.

It has been discussed in a previous blog post, explained in a video demo, and it is available for sale on Qdabra’s website. If you have any questions, please contact us at support (at) Qdabra (dot) com.

Imagine that you created an InfoPath form template where users can include an attachment. You published the form template to a SharePoint form library, and then your users submitted hundreds of forms. Each of those forms contains attachments, but those attachments are "stuck" inside your xml forms!

Luckily, using the DBXL Migration Tool, you can extract those attachments from your InfoPath forms, and store them in a separate location.

Qdabra Software has put together a package you can download, which includes a PDF guide as well as sample forms. To obtain it, simply click here.

When using QueryDB or QuerySharePoint in an InfoPath 2010 form, you might encounter behavior that is different from the behavior you are used to in InfoPath 2007.  When you get to the screen below, you enter values (per our previously documents for QueryDB and QuerySharePoint). If you click Back in the Data Connection Wizard, the values are removed.

In addition, if you finish the Wizard, and set the data connection to execute on load, the data connection will fail in InfoPath 2010.

This is something that changed from InfoPath 2007 to 2010.  InfoPath 2010 behaves differently for some data connections, including QueryDB and QuerySharePoint.

In InfoPath 2007, you could:

• Enter the Sample Value in the Data Connection Wizard.
• Enter values in the following screen (labeled “Set Value”)
• Set the data connection to run on load.
• Preview the form and get results as expected.

If you follow the same steps in InfoPath2010, the data connection may fail on load. Therefore, in InfoPath 2010, we recommend the following:

• When you create the data connection to QuerySharePoint, set it to NOT execute on load.

• In your form’s On Load rules, add a rule that will:
• Set the value of the parameters (e.g. listUrl and query) using “Set a field’s value”.
• Query using the data connection.

After injecting an InfoPath form with qRules, you might be unable to open the XSN in the designer and then Preview. The error indicates:

InfoPath cannot open the selected form because of an error in the form's code.
Policy settings prevent opening Internet forms with managed code. To fix this problem, contact your system administrator.

We have seen this error:

• on machines that are not joined to a domain
• after performing an Internet Explorer upgrade, since these updates might reset your settings.

If you are seeing this error, there are two possible fixes to consider.

A. Modify the Internet Explorer security option causing the issue:

1.    Launch Internet Explorer.
2.    Click the Tools button, and then click Internet Options.
3.    On the Security tab of the Internet Options dialog box, select the Local Intranet zone, and then click Sites.
4.    In the Local Intranet dialog box, clear the Automatically Detect Intranet Network check.
5.    Select all other check boxes.

6.    Click OK twice.
7.    Preview your form.

B. If you are unable to use the solution above, specify a preview domain in the Form Options dialog box of your form template. This forces InfoPath to believe that the form is being opened in the specified domain. The form must be set to Domain Trust for this option to work.

1.    Launch Internet Explorer.
2.    Click the Tools button, and then click Internet Options.
3.    In the Security tab, select the Local Intranet zone, click Sites, and then click Advanced.
4.    Add (or ensure that you've already added) the website to the domain you will use for previewing.
5.    Click Close, and then click OK twice.
6.    Open your InfoPath form in Design mode.
7.    Choose Form Options from the Tools menu.
8.    Select the Preview category.
9.    In the Domain text box, type the website that you added to the Internet Explorer Local Intranet Websites.
10.    Click OK.
11.    Preview your form.

This technique comes from one of Qdabra’s own customers, John Shaw, who is a qRules user. This cool idea will iterate the SaveToSharePoint command for multiple file attachments. This tutorial builds on the example show in a previous document by making the command repeating.

1.    Create a new, blank form and inject it with qRules. For information on how to do this, please refer to the qRules User Guide.

2.    Create the following initial schema, where DetachFile is a Boolean attribute, which defaults to false. For information on the qRulesLink and qRulesFilename, see the qRules User Guide.

3.    Set a text box (AttachmentName) in the repeating section. This field allows the user to name the attachment being uploaded.

4.    On the Boolean DetachFile node, create a rule that set the command node in the QdabraRules secondary data source to the command SaveToSharePoint. This rule will only execute when DetachFile is equal to true. The command will look like this:

concat("SaveToSharePoint /url=<YOUR_LIBRARY_URL> /xpath= /my:myFields/my:ContainerGroup/my:RepeaterGroup/my:Attachment /name=", AttachmentName, " /overwrite=no")

[It makes a difference if the command has "/overwrite=no". If it is set to YES, it will only ever use the first occurrence of the /name parameter. When it is set to NO, each item in the repeating table is given its correct, corresponding name.]

5.    Add a second action to reset DetachFile back to false.

6.    Design the form to show the repeating section. The exact design is up to you, but the screenshot below shows an example:

7.    Add a button to the form and label it “Upload attachments”. This button will use rules, and its only action is to set the Boolean attribute of the attachment field to true.

Now when a user attaches more than one attachment and provides a filename for each attachment, clicking the button will iterate thru each attachment to upload it to SharePoint.