1. Alexander Manes
  2. PowerBuilder
  3. Tuesday, 28 May 2019 09:07 AM UTC

Hello,

a customer of our is running our PowerBuilder application on a Windows Server 2016 Terminal Server and reported that after a while users randomly cannot print anymore.

When they restart our application, they can print again.

Important: All of the customer's printers are installed locally on the server. The users have not installed client-side printers that are added to the remote session (we are aware that there are other issues on Windows Server 2016 specific to that)

 

We discovered that every call within the PowerBuilder application that gets or sets the default printer seems to fail: e.g. PrintGetPrinter() seems to return ?

From this moment on, no PowerBuilder printing of DataWindows etc. is possible anymore!

Unfortunately we have no specific observations what is happening on the server that makes the native PowerBuilder functions fail from then on.

As a workaround we tried to choose a different printer within the application and use it. Not working!

While the PowerBuilder printing is not workin anymore, other applications can still print on all installed printers and even a document viewer embedded into our PowerBuilder application can print just fine using its own printing dialog. Only the native PowerBuilder printing functions and dialogs all fail!

Restarting the applications immediately restores printing functionality, but users have to interrupt their work and start over again which is a big issue for them.

 

Originally, we discovered this using PowerBuilder 2017 Build 1666.

We are aware that a number of issues involving printing in a remote environment on Windows Server 2016 have been addressed and fixed in PowerBuilder 2017 R3 Build 1880, e.g. this spcific to client-side printers attached to the remote session:
https://community.appeon.com/index.php/qna/q-a/windows-server-2016-and-default-client-printer

 

We have migrated and tested with PowerBuilder 2017 R3 Build 1880.

Our problem still exists in PowerBuilder 2017 R3 Build 1880!

Has this been addressed?

Is there a bugfix or a workaround that would quickly solve our customer's issue?

 

Thanks.

Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 29 May 2019 16:01 PM UTC
  2. PowerBuilder
  3. # 1

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

 

Comment
There are no comments made yet.
Alexander Manes Accepted Answer Pending Moderation
  1. Friday, 7 June 2019 15:07 PM UTC
  2. PowerBuilder
  3. # 2

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?

Comment
  1. Chris Pollach @Appeon
  2. Friday, 7 June 2019 18:22 PM UTC
Hi Alexander;

It seems that that fix was missed in PB2017R3 however, the main Support Team seems to indicate to me that this fix was included in the new PB2019GA release (May 31, 2019).

Regards ... Chris
  1. Helpful
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Friday, 7 June 2019 22:07 PM UTC
  2. PowerBuilder
  3. # 3

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

Comment
There are no comments made yet.
Heiko Betzler Accepted Answer Pending Moderation
  1. Thursday, 13 June 2019 06:13 AM UTC
  2. PowerBuilder
  3. # 4

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

Comment
  1. Chris Pollach @Appeon
  2. Thursday, 13 June 2019 17:51 PM UTC


Hi Heiko;



It seems that that fix for this issue was missed in PB2017R3 MR02 (build 1880). However, the fix for this printer issue under "Terminal Server" is now included in the new PB2019GA release (May 31, 2019) - according to the information I saw from the Appeon Support team.



Regards ... Chris
  1. Helpful
  1. Alexander Manes
  2. Monday, 17 June 2019 14:26 PM UTC
Hi Chris,

we have already tried out the fix provided by the DLL files in Support Ticket # 1878.



So is the fix that made it into PB2019GA the exact same fix/code that is provided by those DLL files which did not solve our specific problem?

Do you know, is there more to the fix in PB2019GA that can possibly solve our specific problem or is our problem actually a whole new issue that is not addressed at all yet?



I'm sorry to bother you and ask this beforehand, but we just cannot recompile with PB2019GA and deploy on the customer's production Terminal Server without intensive inhouse testing, so unfortunately this is not a quick test to be done in a day.



If you come to the conclusion that this is a whole new issue, do you have any advice how to log and debug what is going on on that Terminal Server that messes up the execution of a simple function like PrintGetPrinter()?



Thank you!

Alex
  1. Helpful
  1. Chris Pollach @Appeon
  2. Monday, 17 June 2019 14:57 PM UTC
Hi Alex;

Here are the fixes included in 2019GA ...

https://www.appeon.com/support/documents/appeon_online_help/pb2019/release_bulletin_for_pb/bug_fixes.html

Regards ... Chris
  1. Helpful
There are no comments made yet.
Alexander Manes Accepted Answer Pending Moderation
  1. Friday, 19 July 2019 14:13 PM UTC
  2. PowerBuilder
  3. # 5

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!

 

Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Friday, 19 July 2019 16:55 PM UTC
  2. PowerBuilder
  3. # 6

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

Comment
There are no comments made yet.
Alexander Manes Accepted Answer Pending Moderation
  1. Thursday, 1 August 2019 08:59 AM UTC
  2. PowerBuilder
  3. # 7

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

Comment
  1. Chris Pollach @Appeon
  2. Thursday, 1 August 2019 14:51 PM UTC
Hi Alex;

Please open a new Support Ticket for your W2016 terminal server printing issue and attached a Test Case for our Appeon Support Team to analyze. Many thanks in advance!

Regards ... Chris
  1. Helpful
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Tuesday, 14 January 2020 17:25 PM UTC
  2. PowerBuilder
  3. # 8

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.   

Comment
  1. Alexander Manes
  2. Tuesday, 14 January 2020 20:53 PM UTC
Hi Mike, as we could not find a solution with Appeon Support (who did a great job in suppoting us), I was recently on site and we found crash logs of the printer driver. The customer is currently fixing that problem by replacing drivers. Possibly, OUR problem has something to do with PB not being able to use the printer after the crash (while other applications which initialize differently can without a restart of the whole application).

Please check if you printer drivers run stable and let us know.

I will also keep everyone updated here as I can get more information...
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.