Data Connections Best Practices - InfoPath Dev
in

InfoPath Dev

Use our Google Custom Search for best site search results.

Data Connections Best Practices

Last post 09-24-2005 01:14 PM by Patrick Halstead. 4 replies.
Page 1 of 1 (5 items)
Sort Posts: Previous Next
  • 09-18-2005 05:51 PM

    Data Connections Best Practices

    New to the InfoPath environment and hoping to find a brief writeup on data connections and the pros and cons of each. Direct SQL ADO access, web services, etc. I have found a number of subtle pros and cons, but feel there should be a compiled pros and cons out there somewhere for efficient comparison. I am not interested in technical howto's simply a best practice summary of sorts. I have already experimented with various solutions only to find there are many subtle issues yet to be discussed before taking one method over another.

    As yet my searches for this have proved unsuccesful so I am posting in hopes someone has a simple link to the material in question. Thanks.
  • 09-19-2005 10:24 AM In reply to

    Re: Data Connections Best Practices

    My two cents has been to use web services as a means for getting and setting data:

    Maintenance – You have a single point for modification.
    Scalability – If your data sources are to change (access to sql server, sql server to SAP, etc.), only the web service implementation needs to be changed.
    Re-usability – Code written to get and set data can now be used for multiple InfoPath forms or other technologies like ASP.NET, .NET Winforms or even a Java application. You are now moving towards a consistent enterprise framework to get and set data.
    Portability – Web services can be written in many different languages and platforms.
    De-coupling – Now your UI layer (InfoPath) is not dependant on your business/persistence layer of your enterprise solution.

    When working with web services I am a fan of passing back and forth XML in string format or you can use an XmlDocument object in .NET (which will tightly couple you to working with .NET).

    One con is that you will have to put a little more elbow grease into your code, but the benefits out weigh that tremendously in the long run.
    Jason
    http://www.k2distillery.com/
  • 09-19-2005 07:36 PM In reply to

    Re: Data Connections Best Practices

    In general, I agree with VT that Web services are a good best practice as they help abstract the data. Some costs are: installing and configuring them, performing security reviews, maintaining the abstraction, error handling, etc. Some of these costs also come up for the other approaches.

    Patrick Halstead [InfoPath MVP]
    InfoPathDev
    Patrick Halstead
    Project Manager at Qdabra
  • 09-22-2005 05:11 PM In reply to

    Re: Data Connections Best Practices

    After testing various solutions I have found the direct ado connection difficult to implement in dynamic environments. Overall annoying to distribute and maintain forms against database changes. Overall I am leaning toward the data services separation from the UI via web services. Appreciate the extra views on the topic.

    Thanks,

    John
  • 09-24-2005 01:14 PM In reply to

    Re: Data Connections Best Practices

    Hi John,
    Thanks for your post. I agree that the ADO.NET stuff is difficult in a dynamic environment.

    Patrick Halstead [InfoPath MVP]
    InfoPathDev
    Patrick Halstead
    Project Manager at Qdabra
Page 1 of 1 (5 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.