Is InfoPath a Database?

[AZJ]

I've been searching the demos and what not, and can't quite figure this
thing out. What's the difference between InfoPath, and say, Excel or
Access? Does it actually STORE the data, or, is it not meant for that?
Is it just a front end for the data, but I still need a backend? How
is this different from Access w/ Forms?

If someone could please explain, or give me examples of what this is
used for, I'd greatly appreciate it! I can't figure out if I should use
this for my main database (thousands and thousands of records, which
all need queries, etc) or, if I should use it for dinky office surveys,
or- if it could be a great 'Task Manager'- I'm just confused. Can
someone explain in more detail on how it stands out from the rest of
the office products?
Thanks
D

 

[MattBell]

Infopath as best I can describe it is an XSL translation tool to allow you to
put a fancy front end on the top of an xml document. It is most certainly
not a database.

What it does better than say excel or access is XML, which if you are using
..net you know is a great boon. We are currently developing an application
which uses Infopath for the front end of a workflow solution hosted in
BizTalkServer 2004. They work very well together because it's all XML nuts
to soup.
Infopath can talk with WebServices very easily, and anything you can't do in
straight XSL you can code behind in C# and get it done.

Think of it as Microsoft Word for XML. When you save a form, it saves as an
..xml document with processing instructions letting it know what Template is
supposed to open with it.

 

[AZJ]

Hmmm- so really- it's a XML front end- that CAN CONNECT to a database
backend? Or- just stand alone for anyone who wants to use forms to
collect data?

How difficult is it to go the other way with it- ie- display/pull data
from a database and have it displayed in a form? If I have an Access
database, how easy/difficult is it to connect InfoPath forms to it?

Also- if I have an access database online- and want to use InfoPath
forms via web and connect THOSE to a database, all through the browser-
is that easily done as well?
Thanks for the reply!
D

 

[MattBell]

Yes, it can connect to a database backend, including Access though I haven't
done any direct database access. We use webservices for everything because
it's just easier to keep everything in XML.

You can only retrieve information from a database, Infopath won't let you
submit data to a database connection. So it's useful as a reporting tool, but
not as an Access Forms type of deal. I think you might be able to use the
SQLXML tools to expose your SQL Server database as a web service which you
can make calls against, but I'm speculating as I've never actually done any
of that.

I don't know how easy your final question is, I don't use Access at all, so
I'm not familiar with how it works. Poke around the forums some, you might
find info about that. Or check out the Infopath SDK documentation, it has a
lot of good information about how you can make Infopath do stuff behind the
scenes.

 

[Vaibhav]

InfoPath allows users to work offline/online, but it is not the same as
asp.net webforms. User should have InfoPath installed on their machines to
view InfoPath forms ,but if you want only read only forms you can convert
them to MHTML and display in browser.

InfoPath forms can access any database either using web services or data
connections.

HTH

 

[Cate]

Hmmm- so really- it's a XML front end- that CAN CONNECT to a database
backend? Or- just stand alone for anyone who wants to use forms to
collect data?

How difficult is it to go the other way with it- ie- display/pull data
from a database and have it displayed in a form? If I have an Access
database, how easy/difficult is it to connect InfoPath forms to it?

I have found the biggest difference for me using Access as my database,
is that InfoPath forms let more than one user do their work at one
time.Access forms would not do this. The data is stored in the database
in the order the users submit their form data at the end of the
day/shift. Or periodically throughout the day...

But the query end of it for us is the best feature. Again, more than
one person can query the database at one time and from the
administration's point of view, there is a limit on what information
different users can access which they like. At the same time, the
administrators had me build them their own set of queries so they could
get the information they needed without hunting down individual
employees. We like it.

 

[rivsys]

You can easily submit through a database connection. A web service is not
required.

BUT, you can't work with so-called long data types (i.e. Memo in Access,
Text, nText in SQL), which is just absolutely stupid, IMHO.

 

[Cate]

We use a work around on this when we run into it.

I've taught the users to watch for the red box. When it pops up, they
have input too many characters (more than 255) in the comments field,
they are instructed to go to the next row in the repeating table, put
in just the bare reference information needed (in this case , their
name, the client's ID number and date), and continue with their entry
in the comments field. Since InfoPath dumps the data into the database
in the order entered, when they query the database (using the client
number as a search criteria), it pulls it back up in the correct order.


Granted, I'm only working with 13 users right now and all are working
at my facility so I can get to them fairly easily if they have a
problem or question... but it might be workable for others in similar
situations.