PowerBuilder and Norwegian/Finish/Serbian string to date conversion on Windows 10

Problem is in system locale on Windows 10.
In Windows 10 Microsoft changed date time formats for some regions:
Finnish, Norwegian Bokmål (“Norway” and “Svalbard and Jan Mayen” variants), Serbian (variants “Cyrillic, Kosovo”, “Latin, Montenegro”, “Latin, Serbia” and “Latin, Kosovo”).
It was internally changed so that it has now the same separator in date and time parts.
For example, previously format was “01.01.2001 11:01” now is “01.01.2001 11.01”.
It is so even if in regional settings user sets “:” as time separator.
It was reported in other systems that on Windows 10 DateTime.Parse(DateTime.Now.ToString()) no longer works correctly for described regions.
More info: http://www.heikniemi.net/hardcoded/2015/08/windows-10-breaks-net-date-parsing-in-certain-locales/
As in my case system locale for users cannot be changed to any other and it is unknown if and when MS will release any fix, solution in PB should be found.
My proposal would be:
Create function DATE in for example w_sheet window so all other windows inherit it.
public function date date (string astr_string);
n_cst_datetime dtm
return dtm.of_getdate(astr_string)
end function
Create helper function of_getdate in pfc_n_cst_datetime:
public function date of_getdate (string astr_date);
return Date(DateTime(astr_date))
end function
So, whenever Date( data ) is called in itemchanged (or other) event, our function would be used instead and it would return correct converted date.

PowerBuilder and SQL Sever ‘row changed between retrieve and update’ error.

One issue I was working on was triggering ‘row changed between retrieve and update‘ error on DataWindowupdate. Code was kinda simple, just retrieve some values in DataWindow, move some values to Deleted buffer and then call update. No other data manipulations etc. Found that table had some database trigger that was fired on delete. Disabled the trigger and there error message was gone. So trigger was causing that. Trigger also was quite simple, just cursor going through deleted rows and selecting and updating few values in other tables.

Googling told me that in Microsoft SQL server, if a table has an insert, update, or delete trigger, the number of affected rows returned to the SQLNRows property of the Transaction object after an INSERT, UPDATE, or DELETE command depends on the driver. With an ADO.NET driver, the value returned is the sum of the rows affected by the command itself and the trigger. When you are connected to Microsoft SQL Server using ADO.NET or OLE DB, you can set the RecheckRows run time database parameter (introduced in PowerBuilder 10.5) to 1 to recheck how many rows of data were affected by the INSERT, UPDATE, or DELETE command itself and return that value in the SQLNRows property. Setting RecheckRows to 1 before issuing an INSERT, UPDATE, or DELETE command causes a SELECT @@ROWCOUNT command to be executed. To improve performance, you should set it only when required, and reset it to the default value of 0 after use. Example: SQLCA.DBParm=”RecheckRows=1″.

Another solution could be setting SET NOCOUNT { ON | OFF } in trigger itself. SET NOCOUNT ON stops the message that shows the count of the number of rows affected by a Transact-SQL statement or stored procedure from being returned as part of the result set. When SET NOCOUNT is ON, the count is not returned. When SET NOCOUNT is OFF, the count is returned. The @@ROWCOUNT function is updated even when SET NOCOUNT is ON. SET NOCOUNT ON prevents the sending of DONE_IN_PROC messages to the client for each statement in a stored procedure. For stored procedures that contain several statements that do not return much actual data, or for procedures that contain Transact-SQL loops, setting SET NOCOUNT to ON can provide a significant performance boost, because network traffic is greatly reduced.

As I had to make fix in PowerBuilder application, adding QLCA.DBParm=”RecheckRows=1″ before and QLCA.DBParm=”RecheckRows=0″ after Update call solved this problem.