Re: Rockwell FactoryTalk Says 'SQL_TIMESTAMP data type is not supported'

Hi,

 

·         your ODBC driver version

psqlODBC is v11.01.000.

 

SQL_DRIVER_ODBC_VER reports “3.51”

[6608-0.002]    info.c[PGAPI_GetInfo]71: entering...fInfoType=77

[6608-0.002]    info.c[PGAPI_GetInfo]1032: p='03.51', len=0, value=0, cbMax=12

 

·         your PostgreSQL database version

v10.9 x86

Running on Windows 10 32-bit

 

·         any error messages you saw on the screen

 

The client application (Rockwell FactoryTalk), has a button which can automatically create the tables in an existing database.

It created a table successfully that DID NOT have a TIMESTAMP column. But I had to manually create two tables that had a TIMESTAMP column.

When I clicked ‘OK’ to accept the changes, I get this error;

 

 

FactoryTalk works fine with Microsoft SQL ODBC.

 

·         the debug log (mylog_????.log) file (you will have to enable the mylog driver option)

 

Attached.

 

 

 

 

 

 

I ran the ODBC Test tool, and connected via ODBC version 2 (as this is what FactoryTalk appears to be using)

[2892-0.001]odbcapi30.[SQLSetEnvAttr]477: Entering att=200,2

 

I then ran a GetTypeInfo on SQL_TIMESTAMP(11), and it returns SQL_SUCCESS

 

But in the logs, it shows this;

[6608-1677.216]odbcapiw.c[SQLGetTypeInfoW]1015: Entering

[6608-1677.216]    info.c[PGAPI_GetTypeInfo]1115: entering...fSqlType=93

[6608-1677.216]statement.[SC_recycle_statement]812: entering self=0052D2E0

[6608-1677.216] qresult.c[QR_Constructor]173: entering

[6608-1677.216] qresult.c[QR_Constructor]242: leaving

[6608-1677.216]statement.[SC_set_Result]531: (0052D2E0, 00539F48)

[6608-1677.216] qresult.c[QR_Destructor]344: entering

[6608-1677.216]    bind.c[extend_column_bindings]718: entering ... self=0052D370, bindings_allocated=0, num_columns=19

[6608-1677.216]    bind.c[extend_column_bindings]762: leaving 004F8C30

[6608-1677.216] qresult.c[QR_set_num_fields]40: entering

[6608-1677.216] qresult.c[QR_set_num_fields]44: leaving

 

It appears the fSQLType changed from SQL_TIMESTAMP(11) to SQL_TYPE_TIMESTAMP(93)…? Could this be what is causing the issue?

 

 

 

Regards,

 

Michael Riksman

Instrument and Control Specialist

Khalda Petroleum Co.

A KPC/Apache Corp. Joint Venture

Salam Base, Egypt

Mob: +20 122 0530603

Email: michael.riksman@khalda-eg.com

ウイルス フリー｡ www.avg.com