Change existing form to update Database. - InfoPath Dev
in

InfoPath Dev

Change existing form to update Database.

Last post 07-14-2005 05:09 PM by Patrick Halstead. 1 replies.
Page 1 of 1 (2 items)
Sort Posts: Previous Next
  • 07-14-2005 01:44 PM

    • www
    • Not Ranked
    • Joined on 06-30-2005
    • USA
    • Posts 5

    Change existing form to update Database.

    I have an existing InfoPath form that the user wants to add the data to a access database and store to sharepoint(which it currently does). The existing form is pretty basic. It has a few repeating sections and repeating tables. My question is what considerations do I need to keep in mind when designing the new form and database. Will I be able update the existing completed forms with the new process. Any help is appreciated. I am fairly new using InfoPath with no experience connecting to a database with InfoPath.

    www
  • 07-14-2005 05:09 PM In reply to

    Re: Change existing form to update Database.

    Hi Jim and welcome back,

    To use InfoPath's default database submit support you have to create a form from the database connection. In other words, you must consume the relational schema from the access DB. This would require starting from scratch and rebinding all of your UI to the database schema.

    Other approaches....

    1. Create a form from scratch and then import your existing form into it by treating the main data source of your existing form as a secondary data source (2DS) in the new form. This will require writing code to map between the 2DS and the new main data source that submits to Access.
    +Pros: reuse existing form somewhat.
    -Cons: lots of mapping required and lots of work. Limited support for shredding to DB tables.

    2. Write code to programmatically write to the Access DB. You can define a 2DS that you populate and write to the Access DB, or you can just write in code on submit.
    +Pros: supports shredding to more complex relational schema. More flexible.
    -Cons: takes much more time, and is more maintenance longterm.

    3. Send data to a Web service that shreds. Our InfoPath Dev Database Accelerator is an example of a web service that shreds existing InfoPath forms into a database. This is a better solution because it requires 0 coding. You set up the database connection and then use another InfoPath form (that comes with the accelerator) to define the mapping.
    +Pros: 0 coding in form, longterm flexible, better design, gracefully handles schema changes in the form (by shredding what it can)
    -Cons: must buy/install Web service

    4. Write code in Access or a separate utility that polls a file drop location and loads the XML into the DB using a server process.
    +Pros: code on the backend is more secure
    -Cons: lots of work and testing, may reduce stability of server, and may not work if the schema for the InfoPath form changes

    For my money (and yours) I'd go with option #3. Please let us know if you have any questions or clarifications.

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