I can't see any problem with this. Filetostr() and Strtofile() are exact opposites of each other, so you should end up with the same PDF file as you started with.
FILETOSTR() AND STRTOFILE() assume that the string processed is of character type. SO they will give the same results provided the type of file processed is TEXT type.
PDF files are not text files.. SO when the FILETOSTR is done on a PDF file, the string taken becomes a character string and the STRTOFILE will save it with a PDF extension but as a text file. SO PDF READER could fail the subsequent read.
Hi Ramani I tested your example and encountered no problems. But maybe with a different version(5.1) of the Reader it could fail.
Do you know a way to make it saver.
Because from an application I wrote we send pdf files by mail to our clients and when the mail is send I want to be able to send it again. So I had the plan to store the files, with filetostr(), in a table memo field.
If it worked, that is nice. I need to stand corrected. But let me try in reality.
Another important thing is that, fileToStr and StrToFile failed in few cases WHEN the fileSize was large. You have to take care in that area also.
Just to send PDF file by email, you dont have to do the code as explained. You can make an attachment of the PDF file directly.. or by simply renaming it to a new name with .pdf and then attach that. It will be lot more safer and simpler that way.
FILETOSTR() AND STRTOFILE() assume that the string processed is of character type. SO they will give the same results provided the type of file processed is TEXT type.
PDF files are not text files.. SO when the FILETOSTR is done on a PDF file, the string taken becomes a character string and the STRTOFILE will save it with a PDF extension but as a text file. SO PDF READER could fail the subsequent read.
I'm not sure I follow that. What do you mean by a text file in this context? Surely, a PDF is just a series of bytes, as is any other file. I might be wrong, but I can't see any reason why FILETOSTR() and STRTOFILE() shouldn't be reversible, regardless of what the file actually contains.
The only possible problem would be if STRTOFILE() appends an eof character (ASCII 26) to the file, but as far as I can see in my tests, that is not the case.
Rather than take a chance on corruption, why not just store the PDF file in a separate directory and put the filename (including full path) into a character field in the database? That would probably also avoid future issues with the memo file (.FPT) becoming unmanageably large.
If you really need to store the .pdf in a memo field, why not simply put the .pdf into the memo field as is, and ignore the use of FILETOSTR() and STRTOFILE()?
I don't understand the purpose of the conversion?
A .pdf file is already compressed - place one in a .zip file and you will see what little difference it makes, so including them in their natural state in a memo field will not cause any significant 'bloat'.
FILETOSTR() is extremely demanding on RAM as it reads the entire file into memory.
If you use the function on a large file on a low specification user machine, you may well run into problems.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.