Copy link to clipboard
Copied
I am trying to create a .FDF file from database data that can be imported into .pdf form fields. I am using a legacy program written in Alaska Software XBase++. Acrobat keeps saying 'There was a problem reading this document(14)' but I can not determine what that means. I can create a test .FDF in notepad tha works just fine. Any ideas would be much appreciated.
 
Thanks for the suggestions. I finally figured out a work around. Instead of creating the .FDF file from scratch within my program, I created it in Acrobat using the export option. Then I open it as Delimited in my program and search & replace the Title/Value pairs and write the new values back to the file. This seems to work fine.
Thanks again for everyones help.
Copy link to clipboard
Copied
What happens when you open the PDF form in Adobe Acrobat?
Copy link to clipboard
Copied
I get the same message if I open an empty form and try to import the .FDF or if I try just openning the .FDF and let it load Acrobat and the PDF using the data. The PDF comes from a government agency and is already a fillable form. I'm trying to set it up so we fill in the form from database data and then send out for signature.
Copy link to clipboard
Copied
Get you the same error when you open the empty form?
Copy link to clipboard
Copied
Can you modify the FDF file generated? If so try removing the /F key. and any other references to the associated file, including the Doc ID.
You could also go through a debug process by removing parts of the FDF until it either works or is mostly empty. This should point out the problem.
Copy link to clipboard
Copied
Hi Thom,
I tried removing the /F, /ID, /UF, /Type, /Catalog which is everything I
figured was not necessary. I did figure out that while open in notepad
I could copy & paste the contents to a new file and the new file works.
This leads me to believe that my program (Alaska XBase++) is either
adding or leaving out a special character that is not displayed. Just
not sure how to work around this.
Thanks for your help
--
David Nelson, President
[personal information removed from email signature by moderator for your protection from scammers]
Copy link to clipboard
Copied
I have to agree with your assessment. If you can paste working text with the same FDF formatting over top of the not working FDF text, then there are some hidden characters, or possibly characters that are encoded differently. Have you checked to make sure the file is all UTF-8?
Copy link to clipboard
Copied
I was under the impression that the ability of interfacing Adobe Acrobat with a database was not supported anymore.
Check this article from KHKonsulting:
Copy link to clipboard
Copied
A FDF file is not a database.
Copy link to clipboard
Copied
I was referring to the legacy software Alaska Software XBase++ that is producing the fillable data for the PDFs.
It may be possible that if the user is getting the data from a web server, like Apache for example, then maybe something needs to be configured on that web server too.
Copy link to clipboard
Copied
Can you share the form?
Copy link to clipboard
Copied
Hi Bernd,
Sorry that I'm not explaining this very well. Let me try to lay it out
from A to Z. I have a .PDF that was supplied by our State D.M.V. they
designed that already has the fields. What I am trying to do is create
a .FDF from within my legacy program. The legacy program is written in
XBase++ by Alaska software and stores data in the old I.S.A.M. dBase
format. The program allows me to create and write to either a delimited
format or SDF format. I chose the delimited format with a single
character field and gave it a file extension of .FDF which fails to
import. I then tried using a feature that allows me to output text
directly to a file rather than a printer which yields the same results.
I'm sure my problem is with the output of my XBase++ program but I am
just not sure how to work around it. I plan next to try creating the
.FDF with Acrobat and then open it with an XBase++ program as an SDF or
DELIMITED file and try to do a search and replace of all the '/V' values
with data from my database.
Thanks for your help
--
Auction David
[personal information removed from email signature by moderator for your protection from scammers]
Copy link to clipboard
Copied
See this support link:
https://doc.alaska-software.com/content/cmd_xppfcref_copy_to.html
May be a step is missed or not using the appropriate syntax.
The link above focuses on using the command COPY TO to export records from a work area to a file.
If this is the method that you're using, maybe the areas of interest that I think may be causing the problem could be the <cDbe> argument.
It says that a character string is used to name the database engine that will be used to manage the resulting file. In addition, It also says that the VIA option cannot be specified if you're using SDF or DELIMTED WITH options.
If SDF is used, an ASCII file will be created but it says that all records and fields have a fixed length... This in my opinion sounds more like it.
But if DELIMITED is used, which also creates an ASCII file, data will be separated by commas and character fields will appear with double quotation marks, and then both the fields and records can vary in length.
The issue with DELIMITED is if when you use this option the WITH BLANK option, character fields will have no additional delimiters.
And if you're using the WITH option with the <cDelimiter> argument it can be specified as a literal or as a character expression in parenthesis.
So maybe you'll need to review these methods again to check if any particular steps were missed.
Copy link to clipboard
Copied
Thanks for the suggestions. I finally figured out a work around. Instead of creating the .FDF file from scratch within my program, I created it in Acrobat using the export option. Then I open it as Delimited in my program and search & replace the Title/Value pairs and write the new values back to the file. This seems to work fine.
Thanks again for everyones help.
Copy link to clipboard
Copied
Ok great!
Thank you for sharing this solution.