Hi Alex,

We are having a similar problem with a customer - after so many prints the printing will fail and they are not able to use printsetup() to set the printer (just keeps returning ? for datawindow.printer after printsetup).  Also, our users are not printing the same datawindow multiple times and then it occurs, it is after multiple printings of different datawindows that it starts to randomly occur.

Describe('datawindow.printer') returns ? when things start to fail.

What is different is that the customer is running an older version of my app (PB 12.5.1) It is also running on a client machine under windows 10 - so for us it is not related to terminal server/thin clients

and as in your case, this is not something that can NOT be reproduced.  it happens when it happens and neither we nor our customer can get it occur.

our users DO switch between a PDF printer and real printer, and the real printers are shared printers on a windows server.  I am wondering if the switching of printers is the cause of this.  When they do a saveas, we use a pdf printer to do the saveas.  

I think PB is looking at the registry for a default printer (at least initially) and then must store this printer information somewhere.  I think where ever it is saving it for the PB session, it is getting corrupted.

I also assume that it works the same in older PB versions as it does in newer ones since you are having a problem with it too.

We will hopefully be upgrading our customer sometime in the next month or so to our PB2017R3 version. with that version, we use the nativepdf, so our customer won't be switching back and forth with the printers.  If it continues, then my next guess is that it may be related to the printer being shared on a windows server.   

Hi Chris,

we have not opened a new case to this as we did not have any better / more detailed information until know.

After integrating workarounds and additional debug information into the customer's software version, we think we are one step further.

It looks like the issues in PrintGetPrinter() are either fixed or never were the problem in our case.

We think the error is in the DataWindow control itself.

When the printing problem occurs, the follwing code seems to return the error (returns question mark ?):

dw_Preview.Describe('datawindow.printer')

It is the DataWindow control that is simply initialised with the current default printer that won't print.

To reproduce our issue on Windows Terminal Server 2016:

A new window opens and a DataWindow control is initialised in the most basic way:

dw_Preview.SetRedraw(False)
dw_Preview.DataObject = is_ReportDataObject
dw_Preview.SetTransObject(sqlca)
ls_DWPrinter = dw_Preview.Describe('datawindow.printer')
ll_RowCount = dw_Preview.of_Retrieve(iaa_Arguments)
dw_Preview.SetRedraw(True)

The user opens that windows, prints and repeats this a couple of times for the same print out of a number of data sets.

Suddenly, say after 5 prints, the printing fails and we see that ls_DWPrinter contains a question mark ?

Can you confirm that the printer initialisation of a fresh DataWindow is different from the logic that PrintGetPrinter() uses?

Is it possible, that there is an error in the printer init of a DataWindow control itself?

Has this been addressed and possibly fixed by now?

Thanks.

Alex

Hi Alexander;

  You could be correct in the fix for ticket #1878 in PB2019 fixes a similar but not the same issue. Support did post that this ticket was fixed on a June 14th reply and it does show up in the PB2019 fixes.

  My suggestion now would be to open a new Support Ticket for your W2016 terminal server printing issue.

Regards ... Chris

Hi Chris,

we have migrated our application to PB2019GA, tested and deployed it to the customer.

Today the customer reported that the problem is still occuring with this version, too.

I think that problem that is fixed in PB2019GA is one and there is still another problem with Windows Server 2016 Terminal Server in the current version of PowerBuilder 2019.

Unfortunately I cannot provide any more detailed information as we cannot debug the situation.

The best ouput we have from the application WHEN IT FAILS is that code example:

string    ls_SystemPrinter
ls_SystemPrinter = PrintGetPrinter()

--> ls_SystemPrinter will contain the value ? --> we display ls_SystemPrinter so we see this output in the application when it fails.

Do you have any ideas how to debug this further?

Are you aware of anything that could cause this behaviour on Windows Server 2016 Terminal Server?

Any ideas what to do about it?

Do you think it makes sense to replace all calls to PrintGetPrinter() in our code with the Windows API GetDefaultPrinter()?

But I suspect that other PB functions like the PB print dialog fail as well.

Thanks a lot in advance!

Good Morning Michael,

my colleague Alexander is out of office this week. He will return next week.

The problem already exists when fetching the printers.

This is the simple code:

string    ls_SystemPrinter
ls_SystemPrinter = PrintGetPrinter()

Best regards

Heiko

Hey Alexander,

Restarting fixes issue -- makes me wonder:

• Are you using "print jobs" PrintOpen; Print*; PrintClose ?
• What datatype does your code use for PrintOpen return value? int, long, int, …
• Or if you print without print jobs

Can you somehow track/log print job number for each job - to see when printing starts to fail?
I would in particular look for job no. 32767 onwards because I have seen this type of issue beforehand.

HTH /Michael

Hi Chris,

we have deployed the DLL files to the customer and checked every day to see if the error ist reoccurring.

Unfortunately, the customer reported that today it did occur again!

The strange observation is that the customer can work with no problem on some days and then something occurs that messes up the printer information in the running PowerBuilder-based application processes. Then the users fix the problem by restarting our application.

We do not know what causes this to happen.

I have one wild guess:

As described earlier, the customer's users work on thin-clients connected to the terminal server. The thin-clients do not have local client-side printers that they could add to the terminal server session.

But if that whole problem is only related to client-side printers being added to the terminal session, could it be that an external administrator that sometimes connects to the server adds his client-side printers to his terminal session and crash the printer information of other running processes???

I don't know if this is possible?

Do you have any guesses or ideas that we could possibly check on the customer's server to get closer to the root cause of this issue???

Any help is appreciated!

Also what I don't understand: Did the fix in those DLLs, provided after PB Build 1858 not make it into PB Build 1880? Or is this a whole new problem that is not addressed at all yet?

Hi Alexander;

  There was a fix provided in Support Ticket # 1878. Can you try downloading the "New fix dll" attachment from that ticket and see if that helps your situation?

  Note: Please back up the corresponding build 1880 DLL before replacing with the above.

Please let us know if that fixes your issue!

Regards ... Chris