Around 10 days ago I posted an inquiry about finding the wrong data and no data in Acrobat reports, even though the correct data was entered before generating the reports. Someone responded referencing a "garbage collection" process in the background, and data lingering in variables and memory even though it had been deleted or removed by a reset action.
I'm finding that as I export FDF data and import it into my forms, the data in the FDF file contains a mixture of data from two separate transactions. I am NOT selectively exporting only certain specified fields, and thereby inadvertently failing to export some data: I am exporting all data in the file using exportAsFDF() and exportAsFDF(true). Clearly the data entered in one section of the collection form was entered, saved and present when the export operation occurred, yet the data that displays in the import target form after the import operation is a mixture of data from the present transaction and a previous transaction.
I've been so impressed with the stability and capabilities of Acrobat, but how can Acrobat forms be marketable or the least bit worthwhile if you experience this kind of unreliability with data export/import? Surely there is a means available to flush old data from the "memory" of an Acrobat form and ensure a reliable export of data to an FDF file. Otherwise, I have wasted countless hours.
Unreliable data export in Adobe Forms
2011-02-22 15:18:10
Answered
My Product Information:
Acrobat Pro 9.4.2, Windows
Acrobat Pro 9.4.2, Windows
2011-02-22 16:46:32
#1
Accepted Answer
I've been working with forms that import/export FDF for a while now, and don't recall experiencing or hearing of this type of thing happening. With some of the other weird behavior you've been experiencing, I'm thinking there's something wrong with the form. Not necessarily something you've done wrong, but some sort of corruption. I'd be very interested in looking at a sample that behaves this way, because if it is a bug in Acrobat, I would like to know more.
2011-02-22 17:56:21
#2
I discovered the problem. You may be correct about the corruption issue but I think it may be cured now.
Recall yesterday I had an odd problem with a field name showing 4 times in the calculation order dialog box. I followed your suggestion and solved that issue, but after venting earlier today it occurred to me yesterday's issue might be related to this new one. I checked the calculation order dialog and found that a few of my calculated fields were not showing up in the calculation order list at all. I copied/cut the formulas, closed & reopened the field properties dialog box, pasted the formula back, closed properties, then rechecked the calculation order dialog and confirmed the subject fields are now back in the calculation order list.Some of these calculated fields are hidden fields in my data collection file, and those fields were (a) not recalculating with the newer data and (b) retaining the results of calculations with data from a previous transaction, and therefore remaining in the exported fdf file, mixed in with new data, and importing into my forms.
I am still leery of this anomaly - which seems to exist independent of my issue - where data does not get flushed from the system with 'this.resetForm(),' and still shows up in reports, but it is a relief in this case to know it was me (as usually is the case) and not the program.
I'm not adverse to showing you my form and if I continue to experience oddities of a similar nature I will.
Recall yesterday I had an odd problem with a field name showing 4 times in the calculation order dialog box. I followed your suggestion and solved that issue, but after venting earlier today it occurred to me yesterday's issue might be related to this new one. I checked the calculation order dialog and found that a few of my calculated fields were not showing up in the calculation order list at all. I copied/cut the formulas, closed & reopened the field properties dialog box, pasted the formula back, closed properties, then rechecked the calculation order dialog and confirmed the subject fields are now back in the calculation order list.Some of these calculated fields are hidden fields in my data collection file, and those fields were (a) not recalculating with the newer data and (b) retaining the results of calculations with data from a previous transaction, and therefore remaining in the exported fdf file, mixed in with new data, and importing into my forms.
I am still leery of this anomaly - which seems to exist independent of my issue - where data does not get flushed from the system with 'this.resetForm(),' and still shows up in reports, but it is a relief in this case to know it was me (as usually is the case) and not the program.
I'm not adverse to showing you my form and if I continue to experience oddities of a similar nature I will.
2011-02-22 20:48:04
#3
This form does appear to me to be seriously botched up.
It might be a good idea to consider redoing it; As a first try, you might start with a blank base form, and try to copy/paste the fields, as well as document- and page-level scripts (if there are). You should also check your preferences, and deactivate "save as... optimizes for fast web viewing".
HTH.
Max Wyss.
It might be a good idea to consider redoing it; As a first try, you might start with a blank base form, and try to copy/paste the fields, as well as document- and page-level scripts (if there are). You should also check your preferences, and deactivate "save as... optimizes for fast web viewing".
HTH.
Max Wyss.
2011-02-23 14:39:18
#4
Thank you. I will consider doing that and if problems continue will certainly. Based on earlier recommendations from this site I deactivated the save as / fast web viewing a couple of months ago.
The form is something I want to protect (as in copyright protection) and I do have it copyrighted on its face, but what is the etiquette on this site insofar as sharing work product with one another?
The form is something I want to protect (as in copyright protection) and I do have it copyrighted on its face, but what is the etiquette on this site insofar as sharing work product with one another?
2011-02-24 07:34:10
#5
Max, if I redo the form in the manner you suggest, as to fields with scripts and/or calculations attached, is it advisable, before copying/pasting a field, to cut the scripts and calculations, place them in a temporary independent editor, then reattach them to their respective fields after each field is copied/pasted?
DSD
DSD
2011-02-24 07:54:03
#6
I don't bother doing that. If you place most of your code in document-level JavaScript, it's easier to manage.
Regarding sending files to people, it's really a matter of what you feel comfortable with. Some people you trust, some you don't (yet). I sometimes offer to look at a document when I find the problem interesting, and it doesn't bother me when they can't or don't want to send it for whatever reason.
Regarding sending files to people, it's really a matter of what you feel comfortable with. Some people you trust, some you don't (yet). I sometimes offer to look at a document when I find the problem interesting, and it doesn't bother me when they can't or don't want to send it for whatever reason.