1. Philippe PILAT
  2. PowerBuilder
  3. Wednesday, 25 July 2018 09:37 AM UTC

Hi everybody,

Using PB 2017 R2 Build 1769 and SQL AnyWhere 16.

I have to pass a DW control between 2 apps using a database table.

In one app (published as powerserver mobile) I retrieve a datawindow control in a window then I insert a row in the table and in one column (long binary) i save the result of GetFullState().

In the other app (PB compiled) I retrieve the long binary column in a BLOB via SelectBlob and then SetFullState() to populate a DW control. SetFullState fails with -1.

The length of the blob generated by GetFullState when the app is run in the PB IDE is different than the length of the blob generated by GetFullState when the app is published to PowerServer (Web or Mobile).

Does anyone have a clue on how to resolve this problem ?

TIA,

Regards.

Appeon Support Team Accepted Answer Pending Moderation
  1. Thursday, 26 July 2018 01:25 AM UTC
  2. PowerBuilder
  3. # 1

Hi Philippe,


1 The blob that was created using GetFullState in PB can’t be used by Appeon if you used standard datawidnow and standard datastore and vice versa.

2 The blob that was created using GetFullState in PB is compatible with Appeon if you used appeondatawindow and appeondatastore(in appeonworkarounds.pbl), but there is one exception, it won’t work for reports that contain nested reports, which is exactly what you are trying to do.

We have a customer who successfully work around this kind of issue by using the .net assembly, please give a try to see if it can satisfy your requirement. Below are the details from this customer for your reference (we have uploaded the related document and PB case to the .net assembly folder on our FTP site: ftp.appeon.com (guest/guest)).

If you need any help please let us know.

I am using the AppeonDotNetComponent NVO to call server-side DLLs from my Appeon web client, including a DLL created with PowerBuilder Classic from a .NET Assembly target.

Functions in this DLL running on the Appeon server can connect to the same database as the calling web client. Data can be retrieved, processed, and updated in the database using datastore.

I’ve included appeon_workarounds.pbl to the Library List of the .NET Assembly target so I can create AppeonDatastore objects. This allows me to retrieve an AppeonDatastore on the server, do a GetFullState, send the blob to the client via a temp table, and then on the client do a SetFullState to an AppeonDataWindow.

I can also retrieve an AppeonDataWindow on the client, do a GetFullState, send the blob to the server via a temp table, and then on the server do a SetFullState to an AppeonDatastore in the PowerBuilder .NET Assembly DLL.

However, in order to get this to work I had to make a number of changes to the AppeonDatastore and AppeonService NVOs in appeon_workarounds.pbl. I had to do this because
• When running as a .NET assembly, some PowerBuilder syntax is not supported.

• DataWindow objects are not deployed to the .NET assembly DLL. In order to use DataWindows you have to either add a PBL containing them to the DLL’s Library List at run-time, or create them from syntax. You have 4 external DataWindows used when processing GetFullState() and SetFullState(). When running as a .NET assembly I’m now creating these from syntax.

• When creating a temporary file your function knows how to do this when running as an Appeon Web application and when running as an NVO in EAServer. I added a third option which uses the Windows TEMP directory when running as a .NET assembly.


Regards,
ZhaoKai

Comment
  1. Philippe PILAT
  2. Thursday, 26 July 2018 06:41 AM UTC
Hi ZhaoKai,

thanks for your answer and workaround. We have decided to adapt the 'robot' PB app to include all DW's and do the full process (retrieve, create PDF, send mail).



Regards,

Philippe.
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 25 July 2018 14:04 PM UTC
  2. PowerBuilder
  3. # 2

Hi Kevin;

      Another great idea - but unfortunately, the ResultSet system object and GenerateResultSet method are unsupported in the PowerServer environment.

     My suggestion would be to just export the DWO's buffer contents directly and then save that into the Blob table. For example:

  • Any   la_data[ ]
  • la_data =  DC/DS.object.data
  • UPDATEBLOB SET = :la_data

       The issue with this approach (or even the GenerateReultSet) vs the Get/Set FullState is that you loose the row & column "state" information. Hopefully, Philippe does not require this in his project.

    Regards ... Chris

    Comment
    1. Philippe PILAT
    2. Wednesday, 25 July 2018 14:10 PM UTC
    Chris,

    the DW is a composite containing 5 other DW ...

    I don't think your solution would work.



    Regards, Philippe.
    1. Helpful
    1. Chris Pollach @Appeon
    2. Wednesday, 25 July 2018 14:16 PM UTC
    You are correct. Neither then would the Get/Set FullState.



    In PB2017R3 though, you will have a JSON Package object where you can package multiple DWO buffers into one JSON data stream. Unfortunately, the JSON Package object will not be in the PS2018 feature set when released later this year. This feature will come in a later PS release.
    1. Helpful
    There are no comments made yet.
    Roland Smith Accepted Answer Pending Moderation
    1. Wednesday, 25 July 2018 14:03 PM UTC
    2. PowerBuilder
    3. # 3

    You might want to compress the resultset prior to saving it to the database. Then in the other app you can decompress it before importing into the DataWindow.

    I have an example of using the free ZLIB library. The example app highlights zip file handling but you can use the of_compress and of_uncompress functions to work with data in-memory. The of_uncompress function needs to know the original size so it will need to be saved to the table.

    http://www.topwizprogramming.com/freecode_zlibwapi.html

    Comment
    1. Chris Pollach @Appeon
    2. Wednesday, 25 July 2018 14:06 PM UTC
    Great idea Roland ... even if Philippe decides to use a JSON result set!
    1. Helpful
    There are no comments made yet.
    Kevin Ridley Accepted Answer Pending Moderation
    1. Wednesday, 25 July 2018 13:50 PM UTC
    2. PowerBuilder
    3. # 4

    That stinks.  What about using a resultset instead of the fullstate blob?

    Comment
    1. Philippe PILAT
    2. Wednesday, 25 July 2018 13:57 PM UTC
    Kevin, the idea behind is that in the second app I don't need to have maintain the dataobjects nor the DB connection. I was using this approach to generate a PDF out of a composite DW. The PDF generated by PB is looking great but the one generated from the published app not. So as I already have a 'robot' PB app I thought this was a solution.



    Regards,

    Philippe.
    1. Helpful
    1. Chris Pollach @Appeon
    2. Wednesday, 25 July 2018 14:12 PM UTC
    Yes, Philippe could use JSON. However the row & column "state" information would not be transmitted as in the data buffer approach.

    FYI: In PB2017R3, PB will have the ability to create a JSON data stream with DW only changed columns & rows. However, this feature will not be present in PowerServer until the PS2018 release later this year.
    1. Helpful
    1. Kevin Ridley
    2. Wednesday, 25 July 2018 15:26 PM UTC
    Why not take the generated PDF and read that into a blob and save that? Then retrieve and display the PDF from Powerserver?
    1. Helpful
    There are no comments made yet.
    Chris Pollach @Appeon Accepted Answer Pending Moderation
    1. Wednesday, 25 July 2018 12:54 PM UTC
    2. PowerBuilder
    3. # 5

    HI Phillipe;

       Unfortunately, you cannot use DataWindow binaries generated using the Get/Set FullState commands between PowerServer and PowerBuilder as each uses a different technical approach to the generation and reconstitution of the DW binary datum. You can certainly use the Get/Set approach between PB based Apps (but only of the same PB version) and the same for PowerServer based apps (same restriction as PB).

       I would recommend looking at using a different format for exchanging data between these technologies that is not software realm specific.

    HTH

    Regards ... Chris

    Comment
    1. Philippe PILAT
    2. Wednesday, 25 July 2018 13:01 PM UTC
    Hi Chris,

    thanks for your answer. I was afraid of this incompatibility. Will have to change my approach.



    Best regrads,

    Philippe.
    1. Helpful
    1. Chris Pollach @Appeon
    2. Wednesday, 25 July 2018 13:14 PM UTC
    Yes, the Get/Set FullState packages the DW object's source along with the datum. The issue is the DW source is quite different in the C++ realm (PB) vs the jScript realm (PS).

    A great idea though in principle.
    1. Helpful
    There are no comments made yet.
    Philippe PILAT Accepted Answer Pending Moderation
    1. Wednesday, 25 July 2018 12:34 PM UTC
    2. PowerBuilder
    3. # 6

    Hi Kevin,

    thanks for your suggestion. The problem is not with the DB : it's the same engine used in Powerserver and in dev ...

    The problem is the blob generated by getfullstate. The size of the is totally different :

    When the blob is generated in PB IDE : size = 283185

    When the blob is generated in teh app published in Powerserver : size = 12456

     

    Regards,

    Philippe.

    Comment
    There are no comments made yet.
    Kevin Ridley Accepted Answer Pending Moderation
    1. Wednesday, 25 July 2018 12:29 PM UTC
    2. PowerBuilder
    3. # 7

    I don't have SQL Anywhere installed on my dev machine so I can't confirm this, but I would try different binary types for your db column.  I'd try binary and varbinary to see if those work.  I'd even try image if the other 2 didn't work.  It should be easy to try, just create a table (or additional columns on the existing table) and write the blob to them all, then selectblob from each and see which one works.

     

    KR

    Comment
    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.
    We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.