Questions? Feedback?powered byOlark live chat software
Bug 2223

[GENERAL] computed field format in .NET assembly 21 March, 2019

Don Olliver
30 January, 2019
Product: PowerBuilder Category: DataWindow
Version: 2017 R3 Publishing: Public
Status: Verifying Priority: P1
Classification: Resolution:
Don Olliver 21 March, 2019
(In reply to Ken Guo from comment #17)
Hi Don,

Firstly, thanks for your understanding of the situation that we are no
longer maintaining .Net Assembly code.

Secondly, you mentioned that if you change [GENERAL] to [General], there are
some fields that have the issue. Could you please tell me what issue is it
in details? 

If the issue only exists in the computed field, I suggest you traverse all
objects in DataWindow via coding and then modify the format of the computed
field, for example:

>String ldwoname = 'compute_6'  // Dynamic get the dwoname from dw syntax
>If dw_1.Describe(ldwoname +".type") = 'compute' and dw_1.Describe(ldwoname +".coltype") = 'number' and dw_1.Describe(ldwoname +".format") = '[GENERAL]' Then
 dw_1.Modify(ldwoname + ".Format='[General]'")
>End If Regards, Ken
Hi Ken, Thank you for your suggestion, it is something we have not tried. We'll give it a shot and get back to you. Regards, Don
Ken Guo 21 March, 2019
Hi Don,

Firstly, thanks for your understanding of the situation that we are no longer maintaining .Net Assembly code.

Secondly, you mentioned that if you change [GENERAL] to [General], there are some fields that have the issue. Could you please tell me what issue is it in details? 

If the issue only exists in the computed field, I suggest you traverse all objects in DataWindow via coding and then modify the format of the computed field, for example:

>String ldwoname = 'compute_6'  // Dynamic get the dwoname from dw syntax
>If dw_1.Describe(ldwoname +".type") = 'compute' and dw_1.Describe(ldwoname +".coltype") = 'number' and dw_1.Describe(ldwoname +".format") = '[GENERAL]' Then
 dw_1.Modify(ldwoname + ".Format='[General]'")
>End If Regards, Ken
Don Olliver 20 March, 2019
(In reply to Ken Guo from comment #15)
Hi Don, 

I further checked with our product management team for fixing the issue.
However, the feedback from them is that the efforts for fixing the issue
would be much bigger than it looks, because: 
1. When we got the whole .NET Assembly source files from SAP, we got little
information about the code design/internal structure. It is super difficult
for our team to understand the intrinsic logics of the product, and even
more difficult to make code changes in it.
2. Our team tried earlier to fix other .NET Assembly issues. It has never
been quite successful.

Since the problem does not exist if the format is changed to [General], we
sincerely suggest that we can do more digging in this direction, and try to
solve the dilemma by working around it. If you need any assistance on how to
create an efficient workaround, we are willing to help.

Regards,
Ken
Hi Ken, I can understand the difficulty in working with complex code that has not been documented, and therefore your reluctance to fix issues. We would appreciate any suggestions for a workaround. Here is what we have tried: 1. Change [GENERAL] to [General] in PB's Datawindow Painter. This corrects the problem with some fields but causes it in others. It’s inconsistent in that some fields need [GENERAL] while others need [General]. If our clients change the formatting on just the specific problematic fields, then yes this works. But there’s not good programmatic way of determining which fields need to be modified. They need to be manually reviewed by a person. 2. Programmatically replace replace [GENERAL] with [General] at runtime. This fails for the same reason as #1 - it corrects the problem with some fields but causes it in others. 3. Create a utility to load datawindow syntax from the database, replace [GENERAL] with [General] and resave the syntax. Again, this fails for the same reason as #1. Regards, Don Olliver
Ken Guo 20 March, 2019
Hi Don, 

I further checked with our product management team for fixing the issue. However, the feedback from them is that the efforts for fixing the issue would be much bigger than it looks, because: 
1. When we got the whole .NET Assembly source files from SAP, we got little information about the code design/internal structure. It is super difficult for our team to understand the intrinsic logics of the product, and even more difficult to make code changes in it.
2. Our team tried earlier to fix other .NET Assembly issues. It has never been quite successful.

Since the problem does not exist if the format is changed to [General], we sincerely suggest that we can do more digging in this direction, and try to solve the dilemma by working around it. If you need any assistance on how to create an efficient workaround, we are willing to help.

Regards,
Ken
Don Olliver 19 March, 2019
(In reply to Ken Guo from comment #10)
Hi Don,

Thanks for providing the test case. We reproduced it on our end.
However, we don’t have a plan to fix this issue yet, since .Net Assembly
function is obsoleted, we discontinued to maintain/enhance it anymore,
including fixing the bugs.

Regarding the .Net functionality, we recommend that you use HttpClient of PB
2017 and the C# functionality of PB 2019.
Currently, please try to delete the ‘[GENERAL]’ in the format or specify a
format such as ‘###,###.00’ and see if the issue still exists.


Regards,
Ken
Hi Ken, Thanks for presenting Appeon's position. Please review my latest discussion with Chris. Can you discuss making a special feature change with the appropriate parties? Regards, Don Olliver
Don Olliver 19 March, 2019
(In reply to Chris Pollach from comment #12)
Hi Don;

   I suspect that Ken is giving you the best advice based on the fact that
the current .Net Assembly feature is being deprecated in PB2019. By that I
mean its still there - just not being developed any further feature wise any
longer. The new direction for Assemblies will be the C# .Net Assembly.
However upon first release, this newer Assembly target will be based on the
.Net Core technology and as such - could have various limitations in release
1.0 (aka PB2019), such as for example limited DBMS vendor and/or DDL/DML
support.

   The above being said, I do not have the decision making authority to
really answer your question about a special feature enhancement. That
decision would have to be vetted through various Appeon channels (like
product management, engineering and even our CEO). So sorry, I cannot
directly answer your "Fund Appeon development for a correction" question. 

   I suspect though that Ken can connect with the above mentioned people and
respond with their perspective on your question. Lets see what they say.

Regards ... Chris
Thank you Chris. I will ask Ken to pursue this within the proper channels. Don
Chris Pollach 19 March, 2019
Hi Don;

   I suspect that Ken is giving you the best advice based on the fact that the current .Net Assembly feature is being deprecated in PB2019. By that I mean its still there - just not being developed any further feature wise any longer. The new direction for Assemblies will be the C# .Net Assembly. However upon first release, this newer Assembly target will be based on the .Net Core technology and as such - could have various limitations in release 1.0 (aka PB2019), such as for example limited DBMS vendor and/or DDL/DML support.

   The above being said, I do not have the decision making authority to really answer your question about a special feature enhancement. That decision would have to be vetted through various Appeon channels (like product management, engineering and even our CEO). So sorry, I cannot directly answer your "Fund Appeon development for a correction" question. 

   I suspect though that Ken can connect with the above mentioned people and respond with their perspective on your question. Lets see what they say.

Regards ... Chris
Don Olliver 19 March, 2019
(In reply to Chris Pollach from comment #2)
Hi Don;

  Thank you for bringing this issue to our attention. I looked through the
other current "open" tickets and could not find any similar issue.

 I do not know if we have a fix coming out for this problem in PB 2017 MR01
due out this week. I will transfer this ticket over to the main
Support/Engineering team now for their review of the situation and what a
possible workaround and/or fix might be.

Regards ... Chris
Hello Chris, I am writing to ask if there is anything Appeon can do to help us with this issue. We understand .NET assembly targets will become obsolete when PB2019 is released. However, we have spent the last year upgrading all our applications to PB2017 R3. This problem with computed fields is the last major problem found during the upgrade process. Unfortunately, as our clients have the ability to modify report syntax this is a show-stopper and prevents us from deploying the upgrades to production. Moving to HttpClient or PB2019, as Ken suggests, is not an option for us. How would you suggest we proceed? Is there an existing process where we could fund an Appeon development effort to correct the issue in .NET assembly targets, event if it means patching an individual dll instead of packaging and distributing an offical release? Regards, Don Olliver Epic-Premier Insurance Solutions
Ken Guo 19 March, 2019
Hi Don,

Thanks for providing the test case. We reproduced it on our end.
However, we don’t have a plan to fix this issue yet, since .Net Assembly function is obsoleted, we discontinued to maintain/enhance it anymore, including fixing the bugs.

Regarding the .Net functionality, we recommend that you use HttpClient of PB 2017 and the C# functionality of PB 2019.
Currently, please try to delete the ‘[GENERAL]’ in the format or specify a format such as ‘###,###.00’ and see if the issue still exists.


Regards,
Ken
Don Olliver 18 March, 2019
Hello Mark,

Have you been able to reproduce the problem using our test case?

Regards,
Don Olliver
Mark Lee 07 March, 2019
Hi Don,

Thanks for your provide the test case. 
We'll work on it and get back to you next week.
Thanks for your patience and understanding.

Regards,
Mark Lee
Don Olliver 06 March, 2019
ComputedFields.zip (4620KB)

Hello Mark,

We have created a test app for the problem with calculations in computed fields. Archive 'ComputedFields.zip' contains the test app and some examples. The app is in the following two folders:

ComputedFieldsOpen PB2017
ComputedFieldsOpen VS2015 in “PDFOpen\bin\x86\Debug” PDFOpen.exe

The folder ending in  PB2017 is a .NET assembly that creates the datawindow and prints it out to “Send To One Note 2016” (change this to any real or virtual printer).  This assembly is called by the VS2015 application in the folder. The application is named PDFOpen.exe and it has one button to call the assembly.

Folder 'ComputedFieldsOpen examples' has a PDF copy of the report generated by an exe created by PB 2017, and a PDF generated by the PB 2017 .NET assembly.

Let me know if you have any questions.

Regards,
Don Olliver
Mark Lee 11 February, 2019
Hi Don,

Thanks for your update.
We will wait for your test case.

Regards,
Mark Lee
Don Olliver 11 February, 2019
(In reply to Mark Lee from comment #4)
Hi Don,

Thanks for reporting this problem.
Kindly can you please provide a simple test case(PBL and C# code) to us to
reproduce it?
Thanks in advance.

Regards,
Mark Lee
Mark, This is a complex item to reproduce, and is taking us some time to create a test case. We will submit it as soon as we can. Thanks, Don
Mark Lee 30 January, 2019
Hi Don,

Thanks for reporting this problem.
Kindly can you please provide a simple test case(PBL and C# code) to us to reproduce it?
Thanks in advance.

Regards,
Mark Lee
Don Olliver 30 January, 2019
Thank you Chris.

Don
Chris Pollach 30 January, 2019
Hi Don;

  Thank you for bringing this issue to our attention. I looked through the other current "open" tickets and could not find any similar issue.

 I do not know if we have a fix coming out for this problem in PB 2017 MR01 due out this week. I will transfer this ticket over to the main Support/Engineering team now for their review of the situation and what a possible workaround and/or fix might be.

Regards ... Chris
Don Olliver 30 January, 2019
Issue with Computed Field.docx (159KB)

When adding a new computed field to a datawindow for a .NET assembly target (PB 2017 R3 or PB 2019 B1), the format of [GENERAL] is used by default. This seems to work fine if the expression is a string. However, if the expression is the value of other expressions being added together, or the sum of a numeric column for all rows + the sum of another numeric column for all rows, a computed field using [GENERAL] does not display on a report. Changing the format to [General] does not have the same problem. See the attachment for steps to reproduce.

The same datawindow in a PB .exe target does display the computed field. We tried changing the the DW syntax at runtime in the .Net assembly, by doing a global replace of format="[GENERAL]" with format="[General]", but this broke other fields. Note - this problem also occurs in SQL Server 2017.

We have spent nearly a year migrating our PB 12.5 application and PB 11.5 COM components into PB 2017 targets. We are submitting this with P1 priority, because until this issue is fixed we cannot move our migrated application and components into production.
OS:
Windows 10 
Platform:
64-bit 
Database Type:
SAP SQL Anywhere 
Database Version:
17