Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
DiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWord
DirectoryUser Groups
Related Topics
Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ...

MS Office Forum / General MS InfoPath Questions / October 2004

Tip: Looking for answers? Try searching our database.

InfoPath should allow database access to be added to an already-e.

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
geekgrrl - 11 Oct 2004 05:09 GMT
This isn't a question, it's more an expression of dismay.  Your documentation
states:

"In order to submit a form to an Access or SQL Server database, you must
start with a new form and design it based on that database. If you add a
database connection to an existing form, you won't be able to submit it to
the Access or SQL Server database. This requirement exists so that InfoPath
can create forms that match the structure of the database. If the form does
not match the structure of the database, InfoPath cannot update the correct
fields in the database when the data is submitted."

This is just stupid -- stupid design and stupid marketing. You're telling me
I'm too stupid to make my pre-existing form fit my SQL Server DB schema. Why
not let the user be the final arbiter of how to make an existing form fit a
new database. You had almost sold me on using this for a major business
process rework but as soon as I read the above, I realized that I'm too lazy
to redo perfectly good forms simply because the database has to be specified
at design time.

No $ale. I don't waste my money on badly designed software that limits my
flexibility.
Steve van Dongen [MSFT] - 12 Oct 2004 03:10 GMT
>This isn't a question, it's more an expression of dismay.  Your documentation
>states:
[quoted text clipped - 11 lines]
>not let the user be the final arbiter of how to make an existing form fit a
>new database.

It's technically possible to manually convert an existing form to work
with a database or webservice.  This is a "requirement" in the sense
that doing so a very time consuming and/or complex task.  Re-designing
the form around the database from the beginning is likely the quicker
alternative and certainly less error prone.

>You had almost sold me on using this for a major business
>process rework but as soon as I read the above, I realized that I'm too lazy
[quoted text clipped - 3 lines]
>No $ale. I don't waste my money on badly designed software that limits my
>flexibility.

--
Please post questions to the newsgroup; everyone benefits.
This posting is provided "AS IS" with no warranties, and confers no rights.
Sample code subject to http://www.microsoft.com/info/cpyright.htm
geekgrrl - 12 Oct 2004 03:49 GMT
> It's technically possible to manually convert an existing form to work
> with a database or webservice.  This is a "requirement" in the sense
> that doing so a very time consuming and/or complex task.  Re-designing
> the form around the database from the beginning is likely the quicker
> alternative and certainly less error prone.

It's also technically possible to find some other product that does a better
job of designing in the flexibility that people need in the real world. If
anything somebody can do with your slackware offers the prospect of becoming
a "very time consuming and/or complex task", it has created a problem, not
solved one. People don't generally pay good money for that.

What you have here is a major design flaw. And this one really did just cost
you a $575,000 software deployment.
Matthew Blain \(Serriform\) - 12 Oct 2004 19:08 GMT
This is a moderatly difficult problem to solve for the general case: take an
arbitrary data source (the form you designed from some source other than
your fixed table) and somehow stick the data into a fixed database.

As Steve points out, you can do this by taking your form and editing all the
connections by hand in the manifest. This is difficult for a person to do,
though it might be a nice feature for some future version.

You can also solve this by adding a 'middle tier': create a web service
which InfoPath talks to and which talks to your database. In some ways this
is a better design: the adapter (web service) can do all sorts of additional
work to make sure the data is valid and/or logged and can insulate the
InfoPath form and other clients from changes in the database. I'm not sure,
but the next version of SQL server may also have some functionality like
this built into the database system.

--Matthew Blain
http://tips.serriform.com/
http://www.microsoft.com/mspress/books/7128.asp

> > It's technically possible to manually convert an existing form to work
> > with a database or webservice.  This is a "requirement" in the sense
[quoted text clipped - 10 lines]
> What you have here is a major design flaw. And this one really did just cost
> you a $575,000 software deployment.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.