Thank you. I understood the concept. There were several CHR(10) and CHR(13) characters those were causing the problem so Now instead of extracting into cursor and Editing it I am using STRTRAN() to Edit the main file. This way other characters etc in the original File are not disturbed. The File created is also working properly now.

Thanks.





>>After rewriting my PDF File(PDF file was of Text Type, not FlateDecode one) using Set Text Merge to command I am able to see all the changes I have in it, correctly.
>>
>>The File opens fine and I could see everything what I needed.
>>
>>But When I close it , the system is asking me "Do you want to save changes to sample.PDF".
>>If I select Yes, the PDF file, that was initially in Plain Text get changed to smaller size file with the Deflated code and works fine thereafter.
>>
>>Is there any this I could save the file from inside my VFP code only as will need to do it for multiple files.
>>
>>Currently I am using Set Merge to with Scan Scan Loop to Write the File.
>>
>>I tried this VFLUSH 'D:\Sample.PDF' Force
>>
>>It tried this FLUSH 'D:\Sample.PDF' Force, but an error was thrown as 'File is not open'
>>
>>Will Flush or Force will work for it ? How ?
>>
>>Thanks
>
>1. What software were you using to verify the contents of the edited PDF file? Was it a text editor? Was it a PDF viewer?
>2. What software was prompting you with "Do you want to save changes to sample.PDF?" Do you get same behavior with the original unmodified file? Does the same message occur with a file that was modified manually in a text editor?
>3. A potential "sticking point" with files that are "simple text file" would be nature of end-of-line sequence. Some software may expect CR/LF (DOS-style) sequence, others may expect LF only (UNIX style) and sometimes CR only ( CR and LF are carriage return and line-feed respectively -- in VFP they are CHR(13) and CHR(10) ). Sometimes there may be sensitivity to presence or lack of leading or trailing blank (unless you enable viewing of end-of-line marker in text editor, diagnosing this may be difficult). It may be possible that a "blank" line needs to have at least one character - a blank. Another potential "sticking point" would be end-of-file -- the old-style CP/M and DOS style ctrl-Z end-of-file marker (e.g. CHR(26) ) could on occasion cause problems.