Typically, the form has a submit button. This works in the same way as a submit button on a web page.
That is, there is a script on a web server (CGI, ASP, PHP, many other possibilities). The script has a URL. The form connects to the URL and sends the form information. Then the script does whatever the programmer wants. Putting it in a database is a frequent activity.
Note too that there are two kinds of PDF form - those made in Acrobat, and those made in LiveCycle Designer.
Thank you for your reply.
We use ASP and I wrote the ASP scripts for the current processing.
What I am having a hard time seeing is how to extract the data.
Ok, I've gone off at completely the wrong tangent.
So, you have an ASP? Does this work with other forms or are you looking to make it work? What input does it expect?
Yes, we have ASP up and running on a Micorsoft IIS server. The "form" that is being filled out is an ASP that is coded to resemble the existing paper form, and once it is filled it is edited/verfied and either the data is sent to a SQL database or if errors exist it is returned to the user for correction. Since the pages are on the secure portion of our site, I cannot send you a link to see the existing pages.
The input expects text, numbers and dates.
You need an ASP which is designed as the back-end, to accept submitted form data. Then the PDF becomes the front end, with a submit button action giving the URL of the web page. If you have coded your ASP as if it were an HTML form this severely limits what you can do in the PDF, and must choose HTML format for the submit.
I'd have to ask, if you have a working HTML (ASP) based solution, what you hope to gain by going PDF? There are so many things that could go wrong - like viewing in FireFox.
The only thing we were trying to do is to give our users a form that would be identicle to the paper form, instead of a programically created page.
I do see your point.