Patrick Halstead

InfoPath Dev

Patrick Halstead

  • Electronic Forms for Today's Web

    What is Web 2.0?

    Back in the ‘90s we had Web 1.0 – static HTML pages and client-server solutions. That was twenty years ago. Nowadays, the Web is more dynamic. Electronic forms push and pull data to and from multiple sources, and they must look good on mobile devices and work well offline. HTML was the standard for static Web 1.0 and XML is the standard for Web 2.0 because it enables offline document storage, and speaks the same language of the many Web services supporting the dynamic Web 2.0 world of today.

    How do Smart Apps Integrate with Web 2.0?

    Smart mobile and Web browser apps no longer rely on server-side validation to submit. Why is that?

    • End users do not want to fill out a form and see an error on submit (it’s a disappointing user experience)
    • Submit connection may be asynchronous which means the confirmation may not come for minutes
    • The app client does not know how to act on the server’s error result (requires custom coding which creates a brittle tight coupling preventing quick change)

    For those reasons, smart apps do validation before submitting. They ensure their data meets the requirements of an XML schema. Submits do not fail. This architecture is called a “loosely-coupling” architecture because there are no constraints on the server. The server simply extracts information in a passive way from the client. No errors. Of course, the app designer is responsible for creating a data source that matches the business process. The server is only responsible for storing the data and extracting details from it. This simplifies solution architectures while allowing change-management flexibility. Server logic goes away. When the app changes the server just updates the mapping it uses to extract data. No system downtime.  XML is the key in enabling this loosely-coupled integration model because it provides client-side schemas. The NoSQL movement is a key in enabling the no-code server-side piece of this puzzle.

    Why InfoPath?

    In spite of Microsoft’s recent deprecation, InfoPath is still the best technology to use for forms projects:

    • Layout is industry standard (HTML) – good-looking, structured forms can be created
    • Data format is open (XML) – supports loosely-coupled architecture and enables easy migration of data to new solutions down the road
    • No code required – supports rich client-side validation with rules; Web service queries or submits can be done without code
    • Mature, feature-rich technology – InfoPath handles millions of forms in production today
    • Low Cost – no new software licenses needed for Microsoft SA customers
    • Reliable Support – Microsoft will continue supporting the filler until 2023

    Who is Qdabra?

    Qdabra is a customer-focused company. We build electronic forms and have helped thousands. We are technology agnostic and we always listen to the unique needs of the business before proposing a solution. As a small boutique consulting services company, we specialize in electronic forms but we have also developed many tools to accelerate projects and empower our customers to get the most value out of their existing software investments. Qdabra’s Web Service Suite (DBXL) and qRules plugin are two of the many tools available from our web site.

    What is DBXL?

    Qdabra developed DBXL in 2004 to fill a glaring gap in the InfoPath and SharePoint landscape. Customers could not report on the repeating data in their forms and 95% of all business process eForms have repeating data. To solve this problem, DBXL supports submitting XML data to any SQL database. DBXL is a loosely-coupled Web service that enables other smart app scenarios. It is not specific to InfoPath and, in fact, can be used to reduce the development cost and improve the architecture for Web development (since it enables a loosely-coupled design). After 10 years of development, DBXL no exists a suite of Web services to reduce the cost of integrating apps with SQL. It provides both query and submit functionality and rich repertoire of tools to manipulate data. The main benefit of the DBXL is that it is a generic Web service and can be used for any number of forms. Instead of creating one Web service per form template, which causes deployment and migration cost, DBXL supports any number of form templates and that results in a huge cost savings since there is only one deployment and migration to a new server or SharePoint farm is easy. In the last few years, we have created cloud versions of DBXL for Amazon Web Services and Microsoft Azure. Visit our Web site for more details:

    What is qRules?

    Qdabra launched our first community site,, back in December of 2003. After a couple years, the InfoPathDev forum was the leading resource for InfoPath questions on the Web and we currently get between forty and fifty thousand unique visitors a month. The problem was that the questions always centered around the gaps in InfoPath. In other words, people were constantly hitting the same issues and we grew tired of responding to each post with the same code snippet. So, we developed a common library to give to people and that library became qRules. Today, qRules has over 150 functions not included in out-of-box InfoPath. The main benefit of qRules is that our customers don’t have to worry about writing code to fill the most common gaps in Microsoft’s InfoPath technology. Rather than hire a developer and have separate libraries for each InfoPath form, qRules provides a common library that can be injected into a form template and used to complete InfoPath filler forms as well as SharePoint browser forms. Recently, we have created a Microsoft Azure Web service for our Office365 cloud customers. Visit our Web site for more details:

    What about the Future?

    Ten years ago SharePoint was barely breathing and ten years from now, SharePoint will likely be something entirely different. Technology changes very quickly, companies split apart and merge. Data formats change much slower than apps. I feel confident that HTML and XML will still be around in 2024. Forms technology that uses those formats today will easily migrate to new “apps” in the future.

    Qdabra is an “eForms” company. We think InfoPath is still the best technology around, but we are customer-focused. We are not technology centric. We’re here to create a solution for you. We have employees certified in K2 smart forms and Formotus mobile forms and we also are happy to implement ServBus or a PDF Share Form solution if you think it would be a better fit. We will happily look at Access or SharePoint list forms too, but they have serious limitations. We just completed a 12-part webinar series titled “After InfoPath” (click here) focusing on migration paths. We also have a matrix you can review to see some of the many forms alternatives. 

    One of those alternatives is Qdabra’s own FormsViewer technology which we are committed to providing for free as open source software. The software currently works on SharePoint 2013 but we intend to provide it for people without SharePoint in the next year. FormsViewer will support both viewing and editing of data and it will use InfoPath XSN format. We hope this will provide an additional migration path for companies over the next few years and we intend to add features to it to extend the technology in the future.  In other words, we will have API compatibility for a large percentage of existing InfoPath forms. InfoPath form services provides about 80% API compatibility for InfoPath filler API features. Formotus provides maybe 70% and FormsViewer will likely be in the same range. Certainly, we can design a form that will work on FormsViewer and InfoPath filler from the beginning too.

  • SPC348: Update on InfoPath and SharePoint Forms

    This morning at the SharePoint Conference in Vegas, Microsoft gave a great presentation to a packed room of >1000 attendees.

    Here's a link where you can download the slide deck: http//

    For those with Yammer accounts, here's Microsoft's post:

    Quick Summary: Greg, Sonya and Bob gave a very positive talk. They demoed Excel surveys, introduced Forms on SharePoint Lists (FOSL), and talked about the evolving roadmap at Microsoft for form solutions targeting IT professionals. Main focus was no-code solutions. Yay! 

    My Thoughts: I love the new open and cooperative atmosphere at this year's conference. From Day 1 the theme was cooperation. Bill Clinton gave a keynote where he said we need to celebrate our differences if we are going to survive as a social species (heady stuff). Right after that Julia demoed a new social media app called Oslo and she did the demo on an iPad. Rah rah for the new inclusiveness!  This theme was a great backdrop to the InfoPath update talk. InfoPath has always been a sharp knife and some people have cut themselves. The new roadmap pushes four technologies forward to support building better forms that work on a variety of devices and provide contextual data that is not-modal.  

    • Excel Surveys - simple surveys that are data-driven and work great from all devices (available in the O365 cloud today)
    • Forms on SharePoint Lists - turn your lists into contextual forms (first release in summer of 2014)
    • Access Web Apps - rich forms that are backed by relational data (available in the O365 cloud today)
    • Word Structured Forms - rich high fidelity forms that print well with structured data that can be integrated with databases (ETA: 2015?)
    • InfoPath - currently, this is still the recommended solution for forms from Microsoft

    Mind the Gap! The majority of rich forms today require repeating data sections. If InfoPath browser support gets removed from the cloud in 3-4 years (see previous blog roadmap), one of the new technologies will have to support this. My bet is on Word's roadmap. 

    Check out our new community site: where we will be highlighting various migration paths for you.

  • Microsoft announces InfoPath 2013 is the last version ... what to do!?

    On Friday, Microsoft announced that InfoPath 2013 would be the last version:

    Many InfoPath form designers, users and business process managers may be wondering what to do.

    Short Summary

    InfoPath technology is currently the best electronic form technology on the market for the following reasons:

    • Low cost - included in SharePoint/O365, office workers can create rich forms that validate input without code
    • Easy to deploy - no client installs required; InfoPath supports browser forms and domain trust
    • Connect to Web services - InfoPath's native XML support means you can easily connect to enterprise data to pre-populate fields and dropdowns without code
    • Good looking forms - InfoPath displays forms in HTML which is Web client and means you can create very good-looking rich forms

    Microsoft has announced that 2013 will be the last version but what's next? 

    • Microsoft will support InfoPath 2013 (and SharePoint 2013) until 2023
    • Currently, there is no specific guidance on Migrating InfoPath
    • Microsoft has hinted that there will be another announcement at the SharePoint 2014 conference in March
    • Because InfoPath format is XML, assuming your InfoPath forms have well-named data sources, it will be easy to migrate your existing form data to another platform
    • Several alternate applications already exist that read and write InfoPath-designed forms:

    Timeline for InfoPath going away (please note: these are my guess and are not based on communication with Microsoft)

    • 2014: Microsoft announces no future InfoPath versions (see blog post above)
    • 2014: Microsoft Office 365 (cloud) toggles InfoPath browser option to be default off
    • 2016: Microsoft Office 365 disables InfoPath for new customers
    • 2016: SharePoint 2016 ships with no support for InfoPath
    • 2016: InfoPath Designer available as a free "sunset" download (???)
    • 2018: Microsoft Office 365 disables InfoPath browser for all cloud customers
    • 2020: Compatibility bugs with service packs prevent filler from working with SharePoint 2016 (???)
    • 2022: Last year of support for InfoPath 2013 filler/designer

    Suggested migration timeline - here is a proposed timeline for you:

    • 2014: wait and see what Microsoft announces new initiatives at SharePoint 2014 conference in March
    • 2014: continue using InfoPath to build / prototype electronic form solutions BECAUSE ITS INEXPENSIVE AND DATA CAN BE MOVED EASILY
    • 2014: start planning migration of InfoPath forms - review other apps, set priorities and requirements, evaluate cost of all viable options, and get organization buy off on plan
    • 2015: perform proof-of-concept migration of  one or two forms to vet and/or re-evaluate plan
    • 2015: perform migration of a business critical form on existing SharePoint site and/or future SharePoint platform to bolster organizational confidence
    • 2015: re-evaluate and revise migration plan based on results of initial migrations
    • 2016: migrate all existing business critical InfoPath forms to existing SharePoint site and/or new SharePoint platform
    • 2017: migrate non-critical forms as needed

    Qdabra Software (providers of InfoPathDev) is here to assist you with your migration.

    Action Items for Now

    • Check out my webinar recording from last week:
    • Check out for updates. We will be updating the site at the end of February and after Microsoft's announcement in March
    • Check out Qdabra's newsletters
    • Create awareness on your team of the potential changes ahead
    • Continue doing what you are doing - Microsoft is still using InfoPath internally and likely will be doing so for many years
    • Stay abreast of the new developments by following #InfoPath on Twitter.

    Lastly, keep in mind that change is the only constant out there. Everything changes eventually so announcing that there will be a change publicly seems a bit pretentious. And, change doesn't always result in improvement. Lots of companies skip upgrading to new versions if the cost-benefit calculations don't make business sense.

    Qdabra Software is committed to providing you and our many customers a positive path forward. We are here to help you continue creating value from your existing IT investment and assist in planning and implementation of future online business processes.

    Thank you! 



  • Upgrading to InfoPath 2013 causes caching errors

    If you have just upgraded InfoPath to 2013 and when you try to open InfoPath forms you get the following error string in your error dialog box details:

    Exception from HRESULT 0x80070002

    it's probably an InfoPath cache issue. I upgraded from Office 2013 Preview to 2013 Production today and noticed that some forms were opening fine but others were not.

    The solution? Run "infopath.exe /cache clearall" command. That solved my problem beautifully.

  • Free Sample: Copying Repeating Data

    This sample form shows two ways to copy repeating data from a secondary data source into your form's Main data source.

    Secondary data sources can be defined in InfoPath Designer from the Data Connections dialog. You can have pull data from a SharePoint list, another InfoPath form (XML file) on your network, tables in a SQL Database or a Web Service.

    In just a few minutes, you can learn how to copy data from this sample form. Just download the attachment, right click and open it in the InfoPath Designer.
    • InfoPath 2007 or InfoPath 2010
  • qRules 2.3 Coming Soon!

    In our upcoming 2.3 release we've added a boat load of new commands inspired by InfoPath fans everywhere.

    New features:

    • Set Caption – set the title bar of your InfoPath form (client only) to something descriptive. No more "form1" etc. You can dynamically set the form's title as the user is filling out the fields. Help users remember which InfoPath windows contain which forms. 
    • Attach To Share PointList – save attachments (files and images) to SharePoint lists as items. Then replace the attachments in your form with a link to reduce size of your XML and make open and submit super fast across any network.
    • Generate Random Number – need to generate a random number for an InfoPath quiz or survey form? This is for you.
    • Get Environment – returns Mobile, Browser, or Client. Use with SetDefaultView to choose which view a form opens with depending on the environment.
    • Refresh SharePoint List Items – use in tandem with Submit To Share Point List to update list items with most recent edits to the list. Supports changes, including deletes. Can be used in either report or update mode. 
    • Get Full Date Time – returns milliseconds for people who want to use date time as a unique ID. Supports optional format.
    • Set Default View – switch view on open using Get Input Parameters or Get Environment to choose a different view to set as default
    • Set Save – gives the form designer access to a variety of previously code-only save options, such as dynamically allowing save, or setting the save location (client only)

    We've also updated our existing commands to make them more powerful and easy to use.

    Updated commands:

    • Submit To SharePoint List – now supports rich text round-tripping to SharePoint lists! We added new parameters to include attachments (single and repeating). Also includes all the options available for Attach To Share Point List (mapping must be created with updated IPToShP List tool)
    • Save To SharePoint – new option to provide data source to SharePoint’s Copy Web Service to allow saving images or files to a different server than where the form resides (no more cross domain issues)
    • Copy Table – fix to prevent the view from being left in a non-updatable state.
    • IPToShP List tool – adds ability to mark a field as rich text for use in submit to SharePoint list OR when using the tool as stand alone
    • qRules Injector – new ability to choose if you want browser or client compat; if you choose client, you can also use SetSave & SetCaption.

    Help us beta test over the next week and receive a big discount!

  • InfoPath Forms 101: Codeless = Less Cost

    Pie in the Sky?

    InfoPath is the best forms editor on the market today because it lets you create rich forms with structured data without having to rely on a developer to code features. Business process owners can quickly prototype and publish forms with no dependency on developers or IT staff to deploy the forms. Less code means less cost to you both in up front development work and long-term maintenance work. You quickly create a form and when changes are needed, you can do them yourself. Well, that was InfoPath's promise at least...

    Profitability Trumps the Best of Intentions

    When I led a team of developers on the InfoPath 2003 team, we used to go around saying that 75% of all forms would not require code. We had the best intentions and truly wanted to believe in that ideal, but the reality was that version 1.0 of InfoPath (2003 SP1) got it backwards – 75% of all forms needed code for simple things like sorting tables, getting user name or checking to see if the form was new, etc. InfoPath 2007 (version 2) wasn’t much better. Sure, a few of these gaps were filled – a UserName function was made available – but the focus was on browser-based forms. InfoPath 2010 invested further in SharePoint (Microsoft has to make money selling SharePoint these days now that Office sales are saturated) and the changes to the rich client were mostly to implement the Office ribbon. Still, today, most forms need a small amount of code to do a few simple things. That’s really too bad because it creates a barrier to most people using InfoPath.

    Finally, the Promised Land!

    After leaving Microsoft we became InfoPath consultants (Qdabra has the most InfoPath MVPs in the World - WooHoo!) and the first thing we did was to create a common library of code snippets to cover these "codeless" gaps. We called this library qRules. qRules lets you use rules in place of code. You know you love creating rules, and so do we - no code required. It’s been nearly two years since we released the first version of qRules. Today, qRules contains ~25 of the most commonly requested functions accessible via rules. We’ve even extended qRules to do things that aren’t available in InfoPath today – like encrypting fields. Finally, with qRules, we can make good on the promise that 75% of all InfoPath forms don’t need code. That’s good for you because you can do more with less and you don't need a developer to do it.  

    Give qRules a try for free today. Here’s a link:

  • InfoPath gaps in SharePoint and SQL

    SharePoint 2007 limitations (MOSS)

    • SharePoint views cannot be configured to show repeating data from an XML form. No workarounds here.
      • Reporting is flat – no repeating data so the data can not be reported on out of the box. You would need to move the data to a database.
      • Export to Excel from InfoPath does not supported for more than one repeating section and not feasible for more than 10-20 XMLs at a time.
    • Document level permissions – you can manually set permissions in SharePoint, but controlling permissions based on document level fields cannot be done automatically and would require extra SharePoint event handlers or code.
    • SharePoint list view performance degrades for large form libraries (3000+ forms). This is a known limitation in SharePoint. Not a limitation if the data is in SQL. Workarounds include:
      • Archive forms so you have <3000 active. Not a solution if you need to see all of them.
      • Restrict views to show very few forms and enable paging. Can’t see all forms.
      • Add DBXL later and use Excel or SRS if you need fast reporting on all forms
    • Form library columns – number is limited (based on data type)
    • Browser-based forms (IPFS)
      • Can’t use SQL – everyone must have InfoPath rich client if directly connecting to SQL. Web Service (e.g. DBXL) is workaround
        You can still use IPFS but it would require creation of a separate hardcoded Web service (~$1-2k), code to impersonate users ($2-4k), or configuration to impersonate network service account when submitting to DB (<$1k) which limits certain scenarios
      • Auto-upgrade doesn’t work
      • Permissions. No locking when form is opened (last writer wins)
    • Submit performance would be slower (~4x slower) going to SharePoint than to a Web Service. No workaround.
    • No Active Directory integration to assign forms and capture username for comments, etc. SharePoint’s GetUserProfile can be used, but does not allow searching for manager/users or enumerating directs.
    • No filtering for prepoluated data, i.e. dropdowns populated from SharePoint lists - all data is populated on load leading to slow load times. Filtering via OWSSVR can be done but requires code. qRules is another alternative. DBXL WSSP is fastest way to do this since it supports parameterized server-side filtering
    • SharePoint out-of-box search does not support wildcard searches for forms (details). You can’t search for App* and find both Apple and Application. DBXL Search Webpart does support wildcard searches albeit the syntax is different from Siebel.

    SharePoint 2010 limitations

    • Using SharePoint Designer to create write-backs to External Content (SQL DB's) is complicated and not recommended for complex data structures.
    • Visual Studio (custom code) is the recommended development tool to use for complex (related) DB write-backs.  DBXL allows you do manage this without code. 
    • BCS cannot be configured on the fly after an InfoPath form is deployed. You have to convert main data source. Also, BCS requires SharePoint licenses.
    • Data migration of XML forms still requires special stsadmin tools (DBXL provides Doc Migration tool).

    Web Service limitations

    • Default Web Service hardcodes data source to parameters in WSDL. Not data-driven. Need 1 Web Service per form (extra cost). DBXL is data-driven and handles any number of forms.

     SQL Database form issues

    • Changes to XSN schema – adding fields to form do not show up in SQL. You have to add to SQL and then convert your main data source. Previous XML data would not migrate forward.
    • Changes to DB schema will invalidate previously saved XML files in SharePoint.
    • Images, rich text, and other non-SQL data types cannot be saved to SQL. Must be saved in XML but then you have migration issues per previous two bullets.
    • No server-side filtering of large SQL datasets – you could add code to do this but it would impact cost $1-2k and probably be specific to each query
    • No locking of data – multiple writes could happen
    • No dynamic role-based permissions – you would have to add users and/or groups to SQL manually and specify READER or WRITER. Can’t dynamically determine reader and writer based on field value. 
    Bottom line: DBXL adds a lot of value for very little cost.


  • Microsoft announces special technical preview of InfoPath 2010 !!!

  • Installing DBXL on Web Server with Separate SQL Machine

    If you are installing DBXL on a Web Server and setting it up to access a separate SQL server machine on your network, you need to add a security login to that separate SQL server machine that enables the machine running DBXL to access it. Use DOMAIN\MACHINENAME$ where DOMAIN is the domain in which both machines are joined and MACHINENAME is the machine name for the server on which DBXL is being installed. You will need to add the $ sign to the end of the machinename.

    The prefered authentication method for this scenario is SQL Authentication. Windows Authentication will work, but you will need to give the server machine account where the Web Service is installed sysadmin access to the SQL instance. In addition, run ASPNET under a domain account.

  • Using DBXL with Existing Databases

    What DBXL does well

    DBXL helps you quickly move the XML data in your InfoPath forms to a SQL database. It also enables web-based solutions and greater fault-tolerance. More detail:

    1. Quickly move your XML file data into a SQL database to enable:

    a. richer reporting – extend SharePoint views with Excel and SQL Reporting

    b. better performance – pull and push data faster with SQL (bypasses ShP)

    c. fine-grained permissions – control read and write at document level based on assignment

    2. Enable Web-based forms – a secondary benefit of DBXL is to act as a “proxy” layer between the InfoPath client and your SQL server enabling internet-based forms:

    a. No VPN? No problem! DBXL is your proxy. Users submitting forms across the Internet may not be VPN’ed into the corporate domain. In that case, DBXL acts as an authentication proxy.

    b. Browser database hops a problem? DBXL is your bridge. Browser-based forms cannot directly submit to a database on another server. DBXL enables this architecture by providing an authentication proxy between SharePoint and SQL.

    c. SQL security holes? DBXL is your gatekeeper.
    Inside the corporate domain, InfoPath forms submitting directly to SQL will either need Windows Authentication (which opens the SQL db up to anyone) or SQL Authentication, which requires storing connection string info in the InfoPath XSN. Both are security risks. DBXL provides a solution here by providing a proxy layer in between your InfoPath form and SQL.

    3. Build robust, fault-tolerant forms – DBXL is a middle-tier web service providing a layer between your InfoPath form and your SQL database.

    a. Abstraction layer provides a buffer allowing changes to take place in the form or in the database without impacting the form submission process.

    b. Mapping between the XML and the SQL data is done in the Web service which stores the XML and logs mapping errors.

    c. Admin can check mapping log after hours to correct issues and re-map XML data to update data in reporting.

    d. This fault tolerant approach is a major cost-saving advantage of DBXL. If your form is down, you lose money. DBXL increases your form’s uptime.

    What DBXL does not do well

    DBXL was not designed to enable InfoPath forms to work with existing SQL databases. Why is that? There are several reasons why existing SQL databases are not fully supported:

    1. To protect data integrity DBXL needs to control data submitted to the database. If someone opens a form from the database, DBXL locks the form to prevent overwrites. However, the lock is stored in DBXL not in the database. While forms are being edited, if a separate process changes the data in the database, that data will be overwritten when the form is submitted. Vice versa, if the separate process updates the data, the XML form will not be updated. These two scenarios lead to data integrity problems. DBXL cannot be used with databases that are also being written by separate processes or applications. Of course, if the separate process or application uses DBXL web methods, there is no issue.

    2. SQL data in previous database cannot be updated. SQL data not in XML format – to preserve data type fidelity, in addition to mapping data from your XML form into your database, DBXL also stores all form data as XML in the database. This XML is the primary store and that’s good for your InfoPath forms because it means you won’t have data type mismatch problems. However, for pre-existing databases the data exists only in SQL, not in XML. DBXL does not support converting existing SQL data into XML. You can pull SQL data into your InfoPath form (using DBXL’s QueryDB web method) and submit as a new XML form, but you can’t update existing data in a SQL database because DBXL does not have correspondence information – it doesn’t know which rows to update if there is no pre-existing XML data. 

    3. Support for constraints in the existing database – existing SQL databases have foreign and primary key constraints that DBXL may not support. For example, DBXL does not support preserving primary key ids for child and grandchildren tables. For new databases, where all data is submitted from your InfoPath form, this is not an issue, but for existing databases that require these constraints, it is the main issue preventing adoption of DBXL.

    If you have an existing database and you would like to create an InfoPath form for it, your best option is to use the InfoPath’s built-in support for databases. If you need Web-based forms, you will have to create a Web service. You can still use DBXL for this scenario, but you will have to create separate tables that DBXL writes to, or make changes to your existing tables and prevent other processes from accessing the existing database.

    Why DBXL doesn’t do UPDATE – Philosophical Reasons

    The simple answer is that supporting SQL UPDATE is not an important scenario. The complete answer is slightly more complex:

    • DBXL is for office workers who love InfoPath not IT departments. Because DBXL doesn’t require programming it empowers office workers to streamline their business data processes without having to go through their IT department. That saves time and money. Supporting existing databases just isn’t the primary goal since existing databases are most often the domain of the IT department. DBXL lets office workers use a database without having to do complex database programming.
    • DBXL enables robust form solutions. You can change your form or your database and the InfoPath form’s submit process continues to work. This is a major cost savings for you since it ensures greater uptime (see last bullet above under the DBXL benefits section). To support SQL UPDATE would require keeping track of mapping information in the InfoPath form’s XML but since this mapping could change between submits it would create complex update scenarios. This isn’t an issue with simple Delete-then-Reshred because we don’t have to figure out what to update. We just delete everything and resubmit.
    Posted Jul 09 2008, 04:14 PM by ErnestoM with 1 comment(s)
    Filed under:
  • Adding Intranet Sites to IE Trusted Sites Makes IE Zone Internet

    Managed code forms that use simple code like System.Environment.Username will fail with a security exception for form templates with domain trust when launched from an Internet IE zone.

    Here are the options:

    1. Remove Trusted Site setting for the intranet site.
      • Pro: this is the best approach since intranet sites shouldn't have to be added to Trusted Sites.
      • Con: could be lots of work if you have other solutions that require IE Trusted Sites.
    2. Make InfoPath form template full trust and require digital certificates and signing.
      • Pro: this is another recommended solution.
      • Con: digital certificates can require a lot of configuration and installation; adoption still low.
    3. Move form libraries to a different server.
      • Pro: this is a workaround that gives us ultimate independence and flexibility.
      • Con: it’s more work to move the form library.
    4. Create a .NET Deployment MSI for Machine code group.
      • Pro: this is an easy thing to do.
      • Con: overwrites the existing .NET Machine settings for all clients where it is installed.
  • Task Panes that Access Managed Code Require Full Trust Security

    Managed code forms that have a custom task pane require full trust security. Unfortunately, you won't be able to make it domain trust since there are security restrictions. InfoPath will let some JScript forms run with a task pane in Domain trust, but for managed code I believe you have to be full trust, since the code in the task pane has access to the managed code and managed code runs with a higher security context.

    JScript forms with a task pane shouldn't have to be full trust since JScript code doesn't run in a secure context like managed code does.

    More details:

    The HTML Window object in the task pane requires full trust full trust security. You will need full trust in most cases because you probably want to do something against the Trident (Internet Explorer's rendering engine, MSHTML.DLL) document and that goes beyond InfoPath OM wrappers to call into unmanaged code. For that you will need full trust security.

    Some of this is documented in the SDK, but is relatively obscure.

  • SharePoint Columns Don't Use Real XPaths to Get Their Data

    Suppose you have a schema with the following structure:


    When you save your form to SharePoint, if you select to promote both coolField entries, then the promotion will fail for the 2nd entry (actually, it will read the first entry instead of the second).

    The reason this happens is because SharePoint XML parser doesn't support namespaces, so the pseudo xpaths are actually just /myFields/coolDocument/coolField, i.e. there's no ns1: prefix. That means that the second column will extract the value from the first coolField.

    More details: the SharePoint XML parser completely ignores the namespaces and has no support for XPath. This is why the XFP uses the name “node“ for the attribute versus XPath. It is not really an XPath but rather a list of element names separated by slashes.


    Don't use or promote elements with the same name if they have different namespaces.

  • IsReadOnly Doesn't Always Work for Attached Forms

    If your form contains logic that checks to see if it is read-only (thisXDocument.IsReadOnly), there is an issue with Outlook where InfoPath will report false positives depending on your Outlook cache settings.

    Most of the time, it doesn't make sense to call IsReadOnly for an attachment, so the workaround would be to determine if your code is an attachment or not and only use IsReadOnly when it is opened from a shared website or local folder.

    Here's some C# code to determine if your form is an attachment or not:

    private string getFormPath()
        string sFormUri = thisXDocument.URI;
        int iPosition = sFormUri.LastIndexOf("/");

        // if path is outlook file cache, this will return ""
        if (-1 != iPosition)
            // Just return path
            return sFormUri.Substring(0, iPosition + 1);
            return "";

    private string getSharePointFolder()
        string sUri = thisXDocument.Solution.URI;
        int iPosition = sUri.LastIndexOf("/Forms/");
        return -1 != iPosition ? sUri.Substring(0, iPosition + 1) : "";
    _fOpenedLocally = (0 != string.Compare(getFormPath(), getSharePointFolder()));

More Posts Next page »
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.