1. Sivaprakash BKR
  2. PowerBuilder
  3. Thursday, 23 December 2021 11:17 AM UTC

Hello,

PB 2019 R3, PostgreSQL 11

Is there any way to print a report in the background and return the control (cursor) to the application immediately ?

In the printing function, we retrieve data from the database in a datawindow, do some setItem and send it to the printer.  

During busy hours, printing takes a couple of seconds, which our users feel that it's slow.  To improve we want to return control immediately to the screen by sending the job to the background.

Any suggestion is welcome.

Happiness Always
BKR Sivaprakash

 

Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 23 December 2021 15:04 PM UTC
  2. PowerBuilder
  3. # 1

Hi BKR ;

   This question is not related to any particular DBMS. The key is to use a secondary process to perform the data retrieval and printing (or PDF generation for that matter). I do this quite often using this feature ...

http://chrispollach.blogspot.com/2019/12/socket.html

  This allows for a secondary App thread for the above work to proceed with the immediate return of control back to the main PB App for the user to continue with their other business transactions. Note that you could also perform this secondary task as a batch PB App running on the DBMS server. This could be via inserting a row into a DB Table and having a Trigger run the external PB App batch print from there too (another idea).

Food for thought.  HTH

Regards ... Chris

Comment
  1. Sivaprakash BKR
  2. Friday, 24 December 2021 11:05 AM UTC
Thanks, Chris,

I Hope Socket programming will open up a whole lot of new ways of programming in Powerbuilder. Will definitely go through it and try to implement to resolve this issue.

  1. Helpful
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Thursday, 23 December 2021 15:14 PM UTC
  2. PowerBuilder
  3. # 2

Hi, Sivaprakash -

PB applications are single-threaded by default... there is no "background" thread in a normal PB app. Everything executes in the main GUI thread.

However, it is possible to create a non-visual object and have PB instantiate and execute code in this NVO in an alternate execution thread. These are called shared objects (this is completely different than shared variables).

There is currently very little helpful information/documentation available on PB shared objects and multi-threading. In my spare time for the last several months I've developed an example PB application that can perform multi-threaded database retrievals using a shared object and written an accompanying tutorial. The app will very soon be submitted for review and publication in the CodeXchange section of the Appeon Community. The tutorial will also be submitted for publication in the Tech Articles portion of the Articles & Blogs area. I'm hopeful I can submit both before the start of the new year, so watch for them in early 2022 if you think this might be helpful to you.

Multi-threading in PB is possible, but it is not trivial or easy to accomplish. I would categorize it as an advanced topic, but yet it is not rocket science... there are simply several very important factors and considerations you need to be aware of and scant resources to help you out. You can look in PB Help for the topic "SharedObjectGet" for an overview of what is involved.

John

Comment
  1. Sivaprakash BKR
  2. Friday, 24 December 2021 11:06 AM UTC
Thanks, John

I'll wait for your release to learn multi-threading.
  1. Helpful
  1. John Fauss
  2. Wednesday, 29 December 2021 19:12 PM UTC
I agree, Chris. Multi-threading is NOT a magic pill that cures all ills. Rather, it's an advanced, specialized tool that's nice to have in your PB Toolbox. That being said, if your app does data retrievals that take longer than five seconds to complete and do not return a large amount of data, then multi-threading might be something that reduces or eliminates "(Not Responding)" aka "ghost" windows in your app caused by waiting for the database to respond... thereby improving the user experience. I discuss the advantages and the disadvantages in my upcoming Tech Article.
  1. Helpful 1
  1. Miguel Leeuwe
  2. Friday, 31 December 2021 01:44 AM UTC
Yep, the memory problems might really want you to consider to use 64 bit executables. Even then you still might face problems.
  1. Helpful
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Wednesday, 29 December 2021 15:34 PM UTC
  2. PowerBuilder
  3. # 3

do you have the printer setup to spool instead of print directly?  it is a windows printer setup setting.  if you have print directly then you wait for the printer to finish.

Comment
  1. Miguel Leeuwe
  2. Wednesday, 29 December 2021 21:51 PM UTC
Exactly what I was thinking!
  1. Helpful
  1. Sivaprakash BKR
  2. Thursday, 30 December 2021 06:47 AM UTC
Thanks, mike S

This setting is already set and working there. I re-verified it.
  1. Helpful
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Thursday, 30 December 2021 19:33 PM UTC
  2. PowerBuilder
  3. # 4

you could build a report server application - the users send a report print request and the reporting application retrieves the data and sends it to the printer.

 

Comment
  1. Sivaprakash BKR
  2. Friday, 31 December 2021 12:44 PM UTC
Yes mike, that's what we plan now.

To store the data with Printed field set to N'o. Another (service) application will fetch those records with Printed value set to N'o and print that and set the value to Y'es. Will be tested and implementing, once the Mobile app gets completed.

  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.