1. Alexander Manes
  2. PowerBuilder
  3. Tuesday, 28 May 2019

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.

Alexander Manes Accepted Answer Pending Moderation
0
Votes
Undo

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
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. Chris Pollach
  2. Thursday, 1 August 2019
There are no comments made yet.
  1. Thursday, 1 August 2019
  2. PowerBuilder
  3. # 1
Chris Pollach Accepted Answer Pending Moderation
0
Votes
Undo

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.
  1. Friday, 19 July 2019
  2. PowerBuilder
  3. # 2
Alexander Manes Accepted Answer Pending Moderation
0
Votes
Undo

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.
  1. Friday, 19 July 2019
  2. PowerBuilder
  3. # 3
Heiko Betzler Accepted Answer Pending Moderation
0
Votes
Undo

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


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. Chris Pollach
  2. Thursday, 13 June 2019
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. Alexander Manes
  2. Monday, 17 June 2019
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. Chris Pollach
  2. Monday, 17 June 2019
There are no comments made yet.
  1. Thursday, 13 June 2019
  2. PowerBuilder
  3. # 4
Michael Kramer Accepted Answer Pending Moderation
0
Votes
Undo

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.
  1. Friday, 7 June 2019
  2. PowerBuilder
  3. # 5
Alexander Manes Accepted Answer Pending Moderation
0
Votes
Undo

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
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. Chris Pollach
  2. Friday, 7 June 2019
There are no comments made yet.
  1. Friday, 7 June 2019
  2. PowerBuilder
  3. # 6
Chris Pollach Accepted Answer Pending Moderation
1
Votes
Undo

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.
  1. Wednesday, 29 May 2019
  2. PowerBuilder
  3. # 7
  • Page :
  • 1


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