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

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

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

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.