I am having trouble with all the options and restrictions to understand the best way to submit form data so that it can talk to other applications like databases.

I would like a field on a form where, while filling out the form, a person can type in a ID number and a query to a database returns name, address, phone etc. The user then continues to fill out other parts of the form that were not completed by the query.

I understand that this will require either a onblur event with JS or perhaps a button?

I would like the query to be sent to a listener application I can write in java and will be listening on the localhost.

The users of the form can either use Reader or Chrome browser.

I can design the form in either LC or Acrobat DC.

I cannot add folder level scripts.

Is this sort of thing possible - there seems to be a lot of conflicting information. I have read alot about FDF, but I am not sure if FDF can be used to "refresh" (or is the word "flatten") while the form is open.

This just means that data will be exported in the form of an HTML page.

Almost correct The data will be posted to a web server as an HTML post request. This means that if you know how to write software that can accept data from a web form, you can also use that to process your PDF form data. This is actually the default format that I use unless I have a very good reason to use either FDF or XFDF.

The only way you get communicate with a server while filling out a form is via the Net.HTTP/SOAP interface, which means that you will need "Forms" rights in your documents for Reader to be able to process these commands. These extended rights cannot be assigned with Adobe Acrobat, you will need the LiveCycle Reader Extensions server solution for that. And, you also need to install a folder level script on every computer that will process these documents, because the Net.HTTP.request function cannot be used from within the document context.

After thinking about this for a bit more, what you could do is keep track of the state of you form: When you fill out the first half of it, you start out in state one. When you need the ID number, you submit the form as FDF data (or XFDF). Your server process then analyzes the data and generates an ID number and creates a new FDF/XFDF data structure that contains the original data, the ID number and a pointer to a blank copy of the document. When this is now downloaded to the client, it will automatically open the linked PDF file and populate the data with the data from the FDF/XFDF file. You are now in state 2, and the user fills out the remainder of the form. When the form is finalized, and submitted, your server process knows that it's no longer required to generate the ID number, but can now save the data/forward it via email/ ...

BTW: Forget about this working in Chrome. You will need Adobe Reader for this to work.

That's more complicated than it needs to be. It seems there is a local program that acts as a web server the the form can be submitted to. Submitting as "HTML" is fine and probably the easiest to parse, but data for any number of fields can be returned in an FDF, so there's no need to load a new form. This has been possible since forms were introduced with Acrobat/Reader 3 and similar to what AJAX provides for HTML forms.

I'm wondering how it's OK to install a web server and scripts to process the form posts but not folder-level JavaScript for Acrobat/Reader.

We have java installed on all our devices for other things - they lets us run our own java programs, but access to \Program Files\ is locked. Strange but true. So I can write a java app to parse the data.

I am curious about your solution - when you say return the result set via FDF - can you explain in a little more detail?

I have taken the existing form and exported the data as FDF so I know the format of the file, but how is this file returned to update in realtime a open form?

I think submitting to a Java app that's acting like a local web server is probably the last approach you should take. Probably the simplest is the XFA form approach, assuming you can set up each client with access to the database.

You mentioned that you can't install folder-level JavaScript because you can't access \Program Files\. While you place app folder-level JavaScript files in there somewhere, user files are placed elsewhere, so if you have the option of adding JavaScript files to the user folder, you could store data in a file there and access it via JavaScript. This would only make sense if the database was relatively static and in;y needed to be updated occasionally.

The web server approach can work, but it involves a lot more work and it's not clear to me why it has to be a local web server. Is the database local to each workstation as well?

The database is a centralized database with a propriety interface on each PC. Suffice to say there is no way that the central database can be accessed from a PDF, hence the reason for a java based "helper" to act as a go between.

Yup, you are right, I was passing a brain stone and not thinking straight

The mechanism that George described is possible and will work, the trick is to get everything working together correctly. You are dealing with a client side and a server side if you want to do this. One of the problem you will run into is how to get access to the FDF or XFDF data when you submit the form data to your server process. It's not done in the obvious way (as a file attachment), the data will be submitted as raw data during the HTTP POST request. Because we don't know how exactly you are going to implement your Java server, I cannot provide any more information about how to do that in Java, but I can tell you that in a Python server based on SimpleHTTPServer, I am using self.rfile, and in PHP I get the data via php://input

I would recommend that for experimenting, you are not working on your own server process, but use a an existing server so that you can concentrate on debugging your problems with the two parts communicating, and not the low level sever stuff. So, either setup you own server and run e.g. a PHP script on the server to receive and send the FDF/XFDF data, or whip up a quick Python web server based on the SimpleHTTPServer in which you define your own do_POST method.