Hi

many many years ago PowerBuilder changed the behavior (I don't know with SQL Anywhere only or all DBMS) how to include the long varchar columns in the where condition on updates, when creating the DataWindow by setting "updatewhereclause=no". See attached print screen from your datawindow.

Regards
Arthur

What is the datatype definition of the "technique" column in the DataWindow? string of length ___?

Hello John,

You can find the datawindow in the .zip file of the demo application I attached.

That would be a char (32766):

Maybe you should go ahead and report a bug and attach all your screen shots & example code.

https://www.appeon.com/standardsupport/search

Hi Gregory;

  Thank you for the test case! This looks lie a product bug / limitation.

  I was also able to replicate this issue as well in PB 2022 R3 build 3356.

  It looks like any time you have a Long Varchar column with or without any other columns in the DWO, the update conflict is ignored by the DWO!  :-(

  However, if you remove the Long Varchar column and use any other combination of columns, then the update conflict is detected by the DWO.

  I would suggest that you open a Support Ticket for this problem and then attach your test case to that ticket.

Many thanks in advance!

Regards .. chris

Hello Chris,

Do you see any viable work around for this defect? It's causing a production issue of data being LOST, which in terms of defects is not goodly.

Warm Regards,

Greg

Hi Greg;

  FYI: This is not a PB bug. I just realized that this AM after pondering this issue last night as the DWO is depending on the WHERE clause processed by the DBMS to inform the DWO that another update has occurred in between. So this AM, I used the PB Demo DB running on my SQL Server 2022 DBMS and then ran your test case against that DB instance ...  and guess what - your test case now worked perfectly! So this is an SA  Bug!!!  :-(

So you will need a patch from SAP for SA v17 to get around this problem.

FYI: Demo DB for other DBMS:  https://github.com/Appeon/PowerBuilder-Project-Example-Database

HTH

Regards .. Chris

Hello Chris,

If this were the case and in fact it was a SQLAnywhere defect, then one would suspect that the same behaviour would be exhibited in an ISQL Session. So I ran a test with 2 ISQL Windows where the initial data in the long varchar column was 'No Data', then in the left ISQL Window:

update examples set technique= 'Changed on left' where example_id = 0 and technique = 'No Data';

COMMIT;

And in the right ISQL Window:

update examples set technique= 'Changed on right' where example_id = 0 and technique = 'No Data';

COMMIT;

And as one would expect the data that ended up in the column was 'Changed on left' as no rows were actually updated in the right ISQL Window (for obvious reasons).

I have no idea of the inner workings of the datawindow engine that determines what constitutes a "Rows changed between retrieve and update", but understand that it is when no rows are updated when they should have been.

Any thoughts on that?

Thanks again,

Greg

Well Arthur,

You were absolutely right. After editing the source code and setting the updatewhereclause=yes for the technique long varchar column, the update acted as expected as follows:

Now I suppose the questions I have for Appeon is why would this have been done and not documented anywhere where the end result of this oversight results in data being over written without the end-users knowledge. And secondly, are there any other datatypes where this may also apply?

Again Arthur, thank you so much for your attention to this.

Kind Regards,

Greg

Hi Arthur;

  FYI: I have now tested Greg's test case with ASE, SQL Server &  PostGreSQL and both respond correctly in capturing the WHERE check on the Long VarChar column in the PB Demo DB I installed on both DBMS servers.So PB seems to be working properly in that regard. The anomaly only seems to be with SA.

Regards .. Chris