1. Paul Shue
  2. PowerBuilder
  3. Tuesday, 8 March 2022 19:50 PM UTC

I am still getting "row changed between retrieve and update" any time I try to update a table where a datetime is in the list of updateable columns.
I tried setting datetimeformat in the ODBC database profile syntax tab but it still fails. Somehow the where clause value for a datetime is not matching the database value. I saw a previous post where an ORACLE fix was to use: ls_dateformat = "ALTER SESSION SET NLS_DATE_FORMAT = ~'dd/mm/yyyy HH24:MI:SS~'". I am using SQL server as indicated on screenshot below. Any ideas?

 

I recently migrated our PB client/server SQL Server application from PB10 to PB2021 successfully. I setup ODB ODBC database profiles and I am able to run. However in dw painter when I select data source I get the error below although table and columns look good in db painter. Also when I change update properties on a datawindow, I also get "table not found" and I receive "row changed between retrieve and update" in app and dw painter when my dw update properties are "key and updateable columns" or "key and modified columns" (on any update). It worked using "Key columns". I have no db triggers or any other users in the app. These datawindows worked fine in PB10/SQL server 2014.  Any ideas would be appreciated.

PB version:





DB painter:

mike S Accepted Answer Pending Moderation
  1. Wednesday, 9 March 2022 04:36 AM UTC
  2. PowerBuilder
  3. # 1

it sounds like you are using sql azure as your development database, and this is not a runtime issue?

 

adding to what chris said, make sure the database login has the dbo schema as its default if that the schema that owns the tables.  That is sql server database user setup.  and make sure it has permissions

i have no problems running on sql azure - really isn't much different than a local sql server

 

Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 8 March 2022 20:20 PM UTC
  2. PowerBuilder
  3. # 2

Hi Paul;

  That could be due the DBO (Database Owner) assigned to the Table. If your DB Login ID does not have the correct privileges, then a table and/or its columns may not be accessible. I would check with your DBA. Also for ODBC driver (DSN), make sure that the UserID your logging into SS has the appropriate permissions from the middle tier.

Regards ... Chris

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.