1. Larry Pettit
  2. PowerBuilder
  3. Tuesday, 2 April 2024 14:10 PM UTC

Please forgive me if any of my statements below are not correct! That's one of the reasons I'm writing this post, to get informed about the current status and clear up any misconceptions on my part.

Since Microsoft SQL Server 2016, the Datetime datatype in SQL Server has had a higher level of precision than PowerBuilder supports. This lack of support is not considered a "bug" by Appeon.  However, it was entered as an enhancement request (according to other posts) many years ago.  It has to do with Datetime being 8 bytes in SQL Server but PB only supports 7 bytes for a datetime variable and column in a datawindow.

Also, Microsoft's preferred datatype is now Datetime2 and it is ANSI compliant which datetime is not.  PB apparently doesn't provide any support for the datetime2 datatype.

This bug (since that's what I consider it) has never been addressed by Appeon.  It forces DisableBind to be set to true, amongst other problems, which causes other issues.

I personally think fully supporting the Microsoft recommended datatype for a datetime should not take 8 years to get implemented.  I also don't think it's an enhancement that can be delayed indefinitely.  I personally think it is a bug that should have been addressed a long time ago.  

Is there any short-term plan to provide FULL support for datetime and datetime2 datatypes in Microsoft SQL Server?

Who is viewing this page
Larry Pettit Accepted Answer Pending Moderation
  1. Wednesday, 3 April 2024 13:16 PM UTC
  2. PowerBuilder
  3. # 1

Just to be clear, I have been using PB since version 2.0a in 1992. My company has built a very successful ERP system using PB that has installations throughout much of the world. So, I am a fan of PB and I am invested in its future.

To answer your question, I don't need greater precision (per se). I need to be able to set DisableBind to 0 which I cannot do due to this precision flaw in PB. I have a temporary workaround but it slows down the system, which is not acceptable.

I am also extremely concerned that Appeon doesn't seem to think it is important to stay up with current database technology. Appeon has had 8 years to deal with this problem (since the release of SQL Server 2016) and it doesn't sound like it is going to be resolved anytime soon, because it is difficult. This gives the PB naysayers a lot of ammunition. Since my ERP is written largely in PB, it doesn't do me any good when PB has a black eye because it doesn't fully support Microsoft SQL Server datatypes. I'm also sorry but your excuse that the change is difficult doesn't have much effect on me. That's just part of the industry. Upgrading our ERP from PB version 2.0a to the current version over the years hasn't been a cakewalk, but we still had to do it to stay competitive. Please find a way to get this moved up on the priority list. In my opinion, it should have been resolved years ago.

Comment
  1. Roland Smith
  2. Wednesday, 3 April 2024 19:49 PM UTC
I think that Appeon should spend more time fixing bugs that sour end users opinion of PowerBuilder instead of creating a new 'no libraries' workspace. I would never use it myself and it isn't something that would even be known by end user management.
  1. Helpful 3
  1. Larry Pettit
  2. Monday, 8 April 2024 13:32 PM UTC
Chris or Roland,

Peter Pang has asked for a simple reproducible example. Do one of you already have one? I'm not going to have time this week to try to create a simple one.
  1. Helpful
  1. Larry Pettit
  2. Monday, 8 April 2024 13:33 PM UTC
Peter is posting on Bug 11851
  1. Helpful
There are no comments made yet.
Larry Pettit Accepted Answer Pending Moderation
  1. Wednesday, 3 April 2024 12:52 PM UTC
  2. PowerBuilder
  3. # 2

Just to keep all the communications in one place regarding this issue, I am posting the following message I received:

 

Comment # 2 on bug 11851 from Peter Pang @Appeon

Hi Larry, Thanks for reporting this problem. Regarding the full support of SQL Server's datetime and datetime2 in PowerBuilder, Appeon has listed it as a plan. Engineers have tried but found problems in the internal test so the progress has been deferred temporarily, but we will continue to figure it out. It involves the most fundamental logic so the impact is a wide range (such as functions like GetItemDatetime/GetItemTime/SetItem/Time/String/datetime, etc.), making it impossible to differentiate individual database handling. I verified the support of DBMS=MSOLEDBSQL SQL Server in PB2022 R3 3289 as follows:1. DateTime type supports precision of 3 digits, for example, 2024/4/3 00:39:55:157;2. DateTime2 type supports precision of 6 digits, for example, 2024/4/3 00:39:55:153333;3. DateTime() and Time() for strings function supports precision of 6 digits, for example, DateTime(today(), time("11:22:33:123456"));3. String() function supports precision of 6 digits, for example, String(ldt_datetime,"yyyy-mm-dd hh:mm:ss:ffffff"). By the way, may I ask in what scenarios do you need datetime precision beyond 6 digits?  

Best Regards,Peter

Comment
There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Tuesday, 2 April 2024 17:36 PM UTC
  2. PowerBuilder
  3. # 3

There are multiple bug reports on this, including one of mine.

Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 2 April 2024 16:33 PM UTC
  2. PowerBuilder
  3. # 4

Hi Larry;

  It is the same issue for the BIT data type as well. Using the DisableBind=1 is a workaround but that can then cause other DML issues for the PB App at runtime.  :-(

  Please open a support ticket for the DT2 data type support. Feel free to also add the BIT data type (also used in other DBMS) in that request as well to be fully supported. Manny thanks in advance!

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.