1. Samir Kothari
  2. PowerBuilder
  3. Thursday, 17 February 2022 17:01 PM UTC

Hello, hoping I can get some assistance on this problem I'm having with a PowerBuilder 2017 R3 Build 1858 application currently in use by my company. The back end is sql server 2016 and all is working well, up until I've had to move to a new testing environment.

The testing was going well in the first testing environment. I was asked to move everything on to a new environment. The database was moved to the new environment and I've changed my ini file to point to this new environment. I opened the application, older windows which seemed to be fine, however this new window accessing a new table is causing an issue. This is the error message :

"Select Error SQLSTATE = 42522 Microsoft SQL Native Client invalid column name 'timestamp'

I have the timestamp in the datawindow. Now if I recreate the datawindow, all seems fine, but I don't think I should have to do that (and am trying to avoid that since it works in other environments) .

Thanks in advance, any help would be much appreciated

Samir

 

 

 

 

 

Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 17 February 2022 19:23 PM UTC
  2. PowerBuilder
  3. # 1

Hi Samir;

   That sounds like your PB App was originally based on the Sybase ASE engine (the original SQL Server). ASE has a special locking feature called "timestamp locking" which is "heads and tails" more efficient than any Microsoft SS's locking mechanisms. When Sybase migrated ASE over to MS-Windows for Bill Gates (who renamed it to SS), TS locking was still there in the early SS releases. However due to MS's short shortsightedness (thanks to Bill Gates who told engineering to remove it - literally), they decided to remove the TS Locking feature from SS (duh). So if your original DWO's were built to use TS Locking - the datatype and column name must be named "timestamp" for TS locking to take effect. Then the DWO also understands what to do in this special type of locking scheme.

   Newer MS SS's use the TS datatype as just another column DT, However, if your DWO uses the column name of "timestamp" it will try to use the TSEqual() ASE based DML command - which of course SS now <sad> no longer supports this command </sad>. So just renaming the column name other than "timestamp" but leaving the datatype the same should alleviate the SS error. Of course, you could also just migrate back to ASE and your DWO's TS Locking will work again - LOL!

HTH

Regards ... Chris

Comment
  1. Chris Pollach @Appeon
  2. Thursday, 17 February 2022 21:15 PM UTC
Here is what the DWO generates when TS Locking is in effect .... UPDATE TS_Test SET description = 'TimeStamp test ' WHERE name = 'Chris' AND tsequal(timestamp, 0x0000000000002a77) (DBI_PREPARE) (1.565 MS /

You cannot see the TSEqual () command unless you trace the SQL in the App at runtime or from the preview pane of the DWO Painter.

Here is my TS test table ...

create table dbo.TS_Test (timestamp timestamp not null, name varchar(20) not null, description varchar(60) not null) ;
  1. Helpful
  1. Samir Kothari
  2. Thursday, 17 February 2022 21:35 PM UTC
Turned out, the issue was a result of one of the columns being populated by a dropdown, driven by a table that was not migrated correctly (missing the timestamp column) to this new testing environment



thank you for your time on this. I've learned something new! ( don't always trust your dba !...just kidding, I'll certainly be sharing your explanation and solution with my team.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Thursday, 17 February 2022 21:46 PM UTC
Excellent news ... glad that you found the issue!

FYI: I was a DBA before being a developer. I wouldn't trust me as a DBA either - LOL!
  1. Helpful
There are no comments made yet.
Olan Knight Accepted Answer Pending Moderation
  1. Thursday, 17 February 2022 18:38 PM UTC
  2. PowerBuilder
  3. # 2

The error message seems to be saying that the NAME of the column is "timestamp", which is, of course, a reserved word.
Is that the case?

Comment
  1. Samir Kothari
  2. Thursday, 17 February 2022 21:08 PM UTC
Yes. At the same time, this column is used in many other windows and seems to be fine so I don't know why that would be an issue now for this one particular window with a new table.

thanks
  1. Helpful
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.