• Add CallEscape='No' to your SQLCA.DBParm.
• Make sure your SQLCA.DBParm has the correct syntax (https://www.appeon.com/support/documents/appeon_online_help/pb2017r2/connecting_to_your_database/ch14s03.html#d0e8273)

• Try changing the query by using 'like' instead of '=', Just don't add the '%' before or after the value (ie, SELECT column_a FROM tableA WHERE column_b = 'Test' to something like this: SELECT column_a FROM tableA WHERE column_b like 'Test')

• This could be cause by the datatime2 datatype in SQL Server. Basically you would need to trim off the fractional seconds. (https://www.appeon.com/support/documents/appeon_online_help/pb2017r2/connecting_to_your_database/ch10s07.html#XREF_42939_Support_for_new)
• This error occurs when you try to write a date that is outside the valid range of dates for the Microsoft SQL Server datetime field. The datetime field can store dates from January 1, 1753 through December 31, 9999. To correct the error, make sure you are using a date within that range. Hence the trimminig off the fractional seconds. (http://support.sas.com/kb/37/066.html)

• Try adding the [dbo] prefix to it (ie, SELECT dbo.ep_buildschedule('TEST'))
• You can also add this to your PBODB170.ini
  • ​PBSystemOwner='sys,dbo' (https://www.appeon.com/support/documents/appeon_online_help/pb2017r2/connecting_to_your_database/apas01.html#XREF_19024_APPENDIX_Adding)

• This could be caused by data integrity in your database. You can try executing: sp_help 'dbo.TableName' on your SQL Server Management Studio to see where the problem is.

• https://www.appeon.com/support/documents/appeon_online_help/pb2017r2/connecting_to_your_database/apas01.html#XREF_19024_APPENDIX_Adding
• https://www.appeon.com/system/files/product-manual/connecting_to_your_database.pdf
• https://www.appeon.com/system/files/product-manual/connection_reference.pdf

I think it is the same we see from SQL Server, I reported it as a bug, but Appeon claims that it is normal.

All SQL is verified by sending it to the current

active DB Profile connection DBMS with a "NO EXECUTE" request added to it. The NO EXEC basically instructs the DBMS's DML Compiler to only parse the DML statement and then return any error code and error message from the parsing

operation to the PB IDE for display to the developer.

   So if you are not connecting to the correct DB Profile, DBMS, wrong database or even the wrong instance of a DB that does not reflect the current schema definition - you will get these errors. This is that way PB has operated since

v2.0.To suppress these messages if you are compiling against a non-current

schema, just set the "Disable DB Connection When Compiling" in the IDE's System Options dialogue's General tab.

Comment from Kim: I think it still is a bug, it definitely changed with 2017 R2. But not a high priority for us...

Hi Don;

  Could you test and see if adding the TRACE option to your PB 12.5.x and PB 2017R2 PB App DB connection, exposes any SQL processing weirdness?

For example ...

• SQLCA.DBMS = "ODB"         - Change to -
• SQLCA.DBMS = "TRACE ODB" 

Then run both apps through an identical transaction against the same SS instance where you are seeing a problem in your PB 2017 App version and see how the SQL processing differs in each Apps SQL log file - created by using the TRACE option.

Regards ... Chris