Using LE9 documentopen() to create a PDF and save it, I get two very different results.

On the demo DB, It creates a PDF (file signature PDF-1.7) which opens fine.

on our test one, it creates a file with file signature PS-Adobe-3.0 which will not open,

giving error 

These two examples use similar code on buttons
Demo:
DocumentOpen("PrintLetter","PDF",concat("Y:\","testX",".pdf"))

Test:
DocumentOpen("ADV_WA_Disp_Print_White_TEST_PDF","PDF",concat("Y:\","test",".pdf"))

Why would one output be PDF format and the other Adobe PS V3? They are on the same computer.

I get the same issue if I try to send one via email, it does what you'd expact apart from making a good PDF

The problem with using DocumentOpen for this is that its a "fire and forget" command which can be overridden by other windows command and end the creation early.

As DocumentOpen() has many other uses where the "default" POST feature is desireable/required we have created a parallel funciton called DocumentRun() that will work more like the Run Procedure function in DQL where the function will wait till the result is produced.

This "waiting" thing has been a problem in DFW since the early days so its a relief to get a function that now handles this properly.

https://www.dataease.com/dg3_HelpView/?PageID=13829&field1=*DocumentRun*

I see that.

It doesnt, however, alter the resulting output, with the PS 3.0 output on one, but the desired PDF 1.7 output on the other. Its this that I really have to sort.

Documentrun() will make it easier to work multiple instances like saving then printing then emailing.

Have you had any thoughts on this PS 3.0 creation instead of PDF 1.7 creation?

Unfortunately it does stop us using that function.

DocumentOpen/DocumentRun is desigend to overrride the default settings on the document when printing it through the functions.

If you get a PS 3.0 output it must be because the rendering is not PDF but PS and hence it must be a mix in the function where the output is generated via the settings on the document rather than the override in the function (a bug obviously). 

To figure this one out we need you to take a screen copy of the Pritner Setttings on both DQL's you print and upload it here/send it to us so we can see if there is any difference and why one is going wrong and the other one is getting it right.

I think that when you see the differences between them you will quickly find a work around for your problem while we will fix it in general.