I'll try to address everything. Let me know if there's something I
missed.
interrelationships and form-Oracle relationships), but I'm a bit unclear on
InfoPath's data storage. I see many articles on submitting a form to a web
service. I'm guessing I'd need to write web service(s) to handle the form
submit, place the form's data in the intranet database, then read the
information in that database as well as any pertinent information in the
Oracle database during form creation and edit events.
Only the data is saved and its strictly as an XML file. If you've
created a FormLibrary in Sharepoint, the rows of items are each one an
XML file while the template and schema are stored in a subfolder for
the whole library. If you save it to a fileshare, its just the data in
<savedfilename>.xml. You need a webservice but there's the path to
the actual infopath form (template and schema) stored in the xml
file's metadata.
When you first start to design the form, you can tell it that you're
going to submit it to an existing SqlServer or Access database and it
will walk you through a wizard to create the connection and import the
schema. Once the form is designed though, you can't go back and set it
up to submit to the database, or if you can, its not trivial (I
assume, I'll always start new in this case and paste what I can
.
This only applies to SqlServer and Access though - for Oracle, you'll
either have to setup a web service or create a livelink through Access
or SqlServer.
You can also submit via email and to HTTP calls, but that's about it
as far as creating a submit without having to write code. With code,
you can get as fancy as you want but IMHO, that pretty much defeats
the beauty of using Infopath. Also, IMHO, the very best way to make an
infopath form available is via Sharepoint. Together they make a
totally awesome solution. In fact, I'd be willing to bet (in total
ignorance though so probably not worth the bits displaying it) that
the up and coming Infopath Form Server is actually a special-function
form of Sharepoint under the covers.
Finally, I see many articles on the capabilities of InfoPath to allow
"offline" editing. This seems like a great idea (and indeed was an oft
requested feature during function requirements gathering), but I fail to see
how such a scenario would play out in my situation. For example, it is
common for field on these forms to be populated with a single value from a
large (~2000 item) list of values. In order to allow "offline" editing, I
can see two scenarios: (a) download all list items for each field (see
comments about InfoPath limits), or (b) allow the user to type in any value
they wish while "offline" and later validate all such fields with multiple
database calls the next time the form is "online." Is this essentially
correct?
I've never created a form for offline use so this question could be
better answered by someone else. I believe you're essentially correct,
but it seems to me that there's also some sort of XML wizardry
available that would allow you to sensibly cache those values in an
XML file acting as a mini-db source...however, I'm still a total
newbie in the XML/XSL/XQuery realm so I actually know not of what I
speak.
One last question: is the InfoPath form editor (as opposed to the form
builder) an HTA (Hyper-Text Application, like, say MS Money, etc.)? Given
that the forms appear to be rendered as HTML and that the validation code is
written in ECMA script, I'm rather tempted to suspect this is the case. If
Right now, the form filler and form designer are one and the same. The
infopath client is capable of both designing and form-filling, though
you can configure it so that its design capabilities aren't readily
available, but the same client is needed regardless. There are three
solutions that I'm aware of that allow you to fill out the form in a
browser however (InfoView, InfoScope, and InfopathDev has a solution
as well) and the next version of Infopath is supposed to make this
available as well, I think, via their new Forms Server.
