[JBoss JIRA] (TEIID-4960) Problems when using External Materialized Views
by Pedro Inácio (JIRA)
[ https://issues.jboss.org/browse/TEIID-4960?page=com.atlassian.jira.plugin... ]
Pedro Inácio commented on TEIID-4960:
-------------------------------------
When using the now deprecated strategy, all goes well.
Options for numbering_plan:
{code:xml}
OPTIONS(
MATERIALIZED 'TRUE',
UPDATABLE 'FALSE',
MATERIALIZED_TABLE 'MnomMaterialized.numbering_plan_cache',
"teiid_rel:MATVIEW_TTL" 86400000,
"teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
"teiid_rel:MATVIEW_STATUS_TABLE" 'MnomMaterialized.status',
"teiid_rel:MATVIEW_BEFORE_LOAD_SCRIPT" 'execute MnomMaterialized.native(''truncate table mnom.numbering_plan_cache_staging;'');',
"teiid_rel:MATVIEW_AFTER_LOAD_SCRIPT" 'execute MnomMaterialized.native(''RENAME TABLE mnom.numbering_plan_cache TO mnom.numbering_plan_cache_temp, mnom.numbering_plan_cache_staging TO mnom.numbering_plan_cache, mnom.numbering_plan_cache_temp TO mnom.numbering_plan_cache_staging'');',
"teiid_rel:ON_VDB_DROP_SCRIPT" 'DELETE FROM MnomMaterialized.status WHERE Name=''numbering_plan'' AND schemaname = ''NumberingPlan''',
"teiid_rel:MATVIEW_SHARE_SCOPE" 'IMPORTED',
"teiid_rel:MATERIALIZED_STAGE_TABLE" 'MnomMaterialized.numbering_plan_cache_staging',
"teiid_rel:MATVIEW_ONERROR_ACTION" 'THROW_EXCEPTION'
)
{code}
Options for numbering_plan_raw:
{code_xml}
OPTIONS(
MATERIALIZED 'TRUE',
UPDATABLE 'FALSE',
MATERIALIZED_TABLE 'MnomMaterialized.numbering_plan_raw_cache',
"teiid_rel:MATVIEW_TTL" 86400000,
"teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
"teiid_rel:MATVIEW_STATUS_TABLE" 'MnomMaterialized.status',
"teiid_rel:MATVIEW_BEFORE_LOAD_SCRIPT" 'execute MnomMaterialized.native(''truncate table mnom.numbering_plan_raw_cache_staging;'');',
"teiid_rel:MATVIEW_AFTER_LOAD_SCRIPT" 'execute MnomMaterialized.native(''RENAME TABLE mnom.numbering_plan_raw_cache TO mnom.numbering_plan_raw_cache_temp, mnom.numbering_plan_raw_cache_staging TO mnom.numbering_plan_raw_cache, mnom.numbering_plan_raw_cache_temp TO mnom.numbering_plan_raw_cache_staging'');',
"teiid_rel:ON_VDB_DROP_SCRIPT" 'DELETE FROM MnomMaterialized.status WHERE Name=''numbering_plan_raw'' AND schemaname = ''NumberingPlanRaw''',
"teiid_rel:MATVIEW_SHARE_SCOPE" 'IMPORTED',
"teiid_rel:MATERIALIZED_STAGE_TABLE" 'MnomMaterialized.numbering_plan_raw_cache_staging',
"teiid_rel:MATVIEW_ONERROR_ACTION" 'THROW_EXCEPTION'
)
{code}
> Problems when using External Materialized Views
> -----------------------------------------------
>
> Key: TEIID-4960
> URL: https://issues.jboss.org/browse/TEIID-4960
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 9.3
> Environment: * Teiid Server 9.3.0
> * Wildfly 10
> * Mysql 5.7.18
> Reporter: Pedro Inácio
> Assignee: Steven Hawkins
> Attachments: server.log
>
>
> The following problem occurs when, apparently, we have two views where one depend on another, and also we use External Materialization.
> The dependent view is never updated due to a "Transaction already associated with request." exception.
> Logs attached.
> The error:
> {panel:title=The exception in logs}
> 2017-06-14 13:51:51,753 WARN [org.teiid.MATVIEWS] (Worker14_QueryProcessorQueue365) Hlbq3jmDWXNl org.teiid.jdbc.TeiidSQLException: TEIID30328 Unable to evaluate mvstatus('NumberingPlan', 'numbering_plan'): TEIID30384 Error while evaluating function mvstatus
> 2017-06-14 13:52:51,803 INFO [org.teiid.MATVIEWS] (Worker14_QueryProcessorQueue368) XAtcLA8RBrLm Materialization of view NumberingPlanRaw.numbering_plan_raw started.
> 2017-06-14 13:52:51,867 ERROR [org.teiid.PROCESSOR] (Worker14_QueryProcessorQueue372) XAtcLA8RBrLm TEIID30019 Unexpected exception for request XAtcLA8RBrLm.-2514910280603581440: java.lang.AssertionError: Transaction already associated with request.
> {panel}
> The VDB:
> {code:xml}
> <model name="MnomMaterialized" type="PHYSICAL">
> <property name="importer.useFullSchemaName" value="false"/>
> <property name="query-timeout" value="600000"/>
> <source name="MnomMaterializedView" translator-name="mysql-override" connection-jndi-name="java:/mnomDs"/>
> </model>
>
> <model name="NumberingPlanCsvData">
> <source name="numberingPlanCsv-connector" translator-name="file" connection-jndi-name="java:/numberingPlanCsvDs"/>
> </model>
> <model name="NumberingPlan" type="VIRTUAL">
> <metadata type="DDL"><![CDATA[
> CREATE VIEW numbering_plan (
> id integer PRIMARY KEY,
> global_title varchar(20)
> )
> OPTIONS(
> MATERIALIZED 'TRUE',
> UPDATABLE 'TRUE',
> MATERIALIZED_TABLE 'MnomMaterialized.numbering_plan_cache',
> "teiid_rel:MATVIEW_TTL" 86400000,
> "teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
> "teiid_rel:MATVIEW_LOADNUMBER_COLUMN" 'LoadNumber',
> "teiid_rel:MATVIEW_STATUS_TABLE" 'MnomMaterialized.status'
> )
> AS
> SELECT ROW_NUMBER() OVER (ORDER BY cns) as id,
> cns
> FROM (EXEC NumberingPlanCsvData.getTextFiles('NumberingPlan.csv')) AS f,
> TEXTTABLE(f.file COLUMNS cns string DELIMITER ';' SKIP 1) AS A;
>
> ]]>
> </metadata>
> </model>
>
> <model name="NumberingPlanRaw" type="VIRTUAL">
> <metadata type="DDL">
> <![CDATA[
> CREATE VIEW numbering_plan_raw (
> id integer PRIMARY KEY,
> global_title varchar(20)
> )
> OPTIONS(
> MATERIALIZED 'TRUE',
> UPDATABLE 'FALSE',
> MATERIALIZED_TABLE 'MnomMaterialized.numbering_plan_raw_cache',
> "teiid_rel:MATVIEW_TTL" 86400000,
> "teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
> "teiid_rel:MATVIEW_LOADNUMBER_COLUMN" 'LoadNumber',
> "teiid_rel:MATVIEW_STATUS_TABLE" 'MnomMaterialized.status'
> )
> AS
> SELECT ROW_NUMBER() OVER (ORDER BY network) as id,
> global_title
> FROM numbering_plan np;
>
> ]]>
> </metadata>
> </model>
> </model>
> {code}
> The Materialized table:
> [code:sql}
> CREATE TABLE status (
> VDBName VARCHAR(50) NOT NULL,
> VDBVersion VARCHAR(50) NOT NULL,
> SchemaName VARCHAR(50) NOT NULL,
> Name VARCHAR(256) NOT NULL,
> TargetSchemaName VARCHAR(50),
> TargetName VARCHAR(256) NOT NULL,
> Valid BOOLEAN NOT NULL,
> LoadState VARCHAR(25) NOT NULL,
> Cardinality BIGINT,
> Updated TIMESTAMP NOT NULL,
> LoadNumber BIGINT NOT NULL,
> NodeName varchar(25) not null,
> StaleCount BIGINT,
> PRIMARY KEY (VDBName , VDBVersion , SchemaName , Name)
> );
> CREATE TABLE numbering_plan_cache (
> id integer,
> global_title varchar(20),
> LoadNumber BIGINT,
> PRIMARY KEY(id)
> );
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (TEIID-4960) Problems when using External Materialized Views
by Pedro Inácio (JIRA)
Pedro Inácio created TEIID-4960:
-----------------------------------
Summary: Problems when using External Materialized Views
Key: TEIID-4960
URL: https://issues.jboss.org/browse/TEIID-4960
Project: Teiid
Issue Type: Bug
Affects Versions: 9.3
Environment: * Teiid Server 9.3.0
* Wildfly 10
* Mysql 5.7.18
Reporter: Pedro Inácio
Assignee: Steven Hawkins
Attachments: server.log
The following problem occurs when, apparently, we have two views where one depend on another, and also we use External Materialization.
The dependent view is never updated due to a "Transaction already associated with request." exception.
Logs attached.
The error:
{panel:title=The exception in logs}
2017-06-14 13:51:51,753 WARN [org.teiid.MATVIEWS] (Worker14_QueryProcessorQueue365) Hlbq3jmDWXNl org.teiid.jdbc.TeiidSQLException: TEIID30328 Unable to evaluate mvstatus('NumberingPlan', 'numbering_plan'): TEIID30384 Error while evaluating function mvstatus
2017-06-14 13:52:51,803 INFO [org.teiid.MATVIEWS] (Worker14_QueryProcessorQueue368) XAtcLA8RBrLm Materialization of view NumberingPlanRaw.numbering_plan_raw started.
2017-06-14 13:52:51,867 ERROR [org.teiid.PROCESSOR] (Worker14_QueryProcessorQueue372) XAtcLA8RBrLm TEIID30019 Unexpected exception for request XAtcLA8RBrLm.-2514910280603581440: java.lang.AssertionError: Transaction already associated with request.
{panel}
The VDB:
{code:xml}
<model name="MnomMaterialized" type="PHYSICAL">
<property name="importer.useFullSchemaName" value="false"/>
<property name="query-timeout" value="600000"/>
<source name="MnomMaterializedView" translator-name="mysql-override" connection-jndi-name="java:/mnomDs"/>
</model>
<model name="NumberingPlanCsvData">
<source name="numberingPlanCsv-connector" translator-name="file" connection-jndi-name="java:/numberingPlanCsvDs"/>
</model>
<model name="NumberingPlan" type="VIRTUAL">
<metadata type="DDL"><![CDATA[
CREATE VIEW numbering_plan (
id integer PRIMARY KEY,
global_title varchar(20)
)
OPTIONS(
MATERIALIZED 'TRUE',
UPDATABLE 'TRUE',
MATERIALIZED_TABLE 'MnomMaterialized.numbering_plan_cache',
"teiid_rel:MATVIEW_TTL" 86400000,
"teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
"teiid_rel:MATVIEW_LOADNUMBER_COLUMN" 'LoadNumber',
"teiid_rel:MATVIEW_STATUS_TABLE" 'MnomMaterialized.status'
)
AS
SELECT ROW_NUMBER() OVER (ORDER BY cns) as id,
cns
FROM (EXEC NumberingPlanCsvData.getTextFiles('NumberingPlan.csv')) AS f,
TEXTTABLE(f.file COLUMNS cns string DELIMITER ';' SKIP 1) AS A;
]]>
</metadata>
</model>
<model name="NumberingPlanRaw" type="VIRTUAL">
<metadata type="DDL">
<![CDATA[
CREATE VIEW numbering_plan_raw (
id integer PRIMARY KEY,
global_title varchar(20)
)
OPTIONS(
MATERIALIZED 'TRUE',
UPDATABLE 'FALSE',
MATERIALIZED_TABLE 'MnomMaterialized.numbering_plan_raw_cache',
"teiid_rel:MATVIEW_TTL" 86400000,
"teiid_rel:ALLOW_MATVIEW_MANAGEMENT" 'true',
"teiid_rel:MATVIEW_LOADNUMBER_COLUMN" 'LoadNumber',
"teiid_rel:MATVIEW_STATUS_TABLE" 'MnomMaterialized.status'
)
AS
SELECT ROW_NUMBER() OVER (ORDER BY network) as id,
global_title
FROM numbering_plan np;
]]>
</metadata>
</model>
</model>
{code}
The Materialized table:
[code:sql}
CREATE TABLE status (
VDBName VARCHAR(50) NOT NULL,
VDBVersion VARCHAR(50) NOT NULL,
SchemaName VARCHAR(50) NOT NULL,
Name VARCHAR(256) NOT NULL,
TargetSchemaName VARCHAR(50),
TargetName VARCHAR(256) NOT NULL,
Valid BOOLEAN NOT NULL,
LoadState VARCHAR(25) NOT NULL,
Cardinality BIGINT,
Updated TIMESTAMP NOT NULL,
LoadNumber BIGINT NOT NULL,
NodeName varchar(25) not null,
StaleCount BIGINT,
PRIMARY KEY (VDBName , VDBVersion , SchemaName , Name)
);
CREATE TABLE numbering_plan_cache (
id integer,
global_title varchar(20),
LoadNumber BIGINT,
PRIMARY KEY(id)
);
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (TEIID-4959) VDB Resource usage restriction options
by Debbie Steigner (JIRA)
Debbie Steigner created TEIID-4959:
--------------------------------------
Summary: VDB Resource usage restriction options
Key: TEIID-4959
URL: https://issues.jboss.org/browse/TEIID-4959
Project: Teiid
Issue Type: Feature Request
Affects Versions: 8.12.10.6_3
Reporter: Debbie Steigner
Assignee: Steven Hawkins
It would be very useful to have configurable options to limit resource usage (CPU, RAM, disk...) by user, query or connection. This would prevent any one user or query from consuming all/disproportionate system resources.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (TEIID-4957) Setting Connection Type on VDB of a Domain Managed server gets set back to default after server restart
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4957?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-4957:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1461168
Bugzilla Update: Perform
> Setting Connection Type on VDB of a Domain Managed server gets set back to default after server restart
> -------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4957
> URL: https://issues.jboss.org/browse/TEIID-4957
> Project: Teiid
> Issue Type: Bug
> Components: VDB
> Affects Versions: 8.12.10.6_3
> Reporter: Debbie Steigner
> Assignee: Barry LaFond
>
> After deploying a VDB to a managed server group, set the Connection type to anything but the default of By_Version, so None or Any. Now restart the server and you'll see the Connection type is reset to the default.
> What I see is that when the change is made a vdb.xml with that new connection-type is written to the /DVserverhome/domain/servers/server-two/data/teiid-data/SampleVDB_1 folder, this folder is deleted upon a restart though so the change is not kept.
> This only happens in Domain mode, running in Standalone mode saves the change because the teiid-data is not deleted on a restart.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (TEIID-4958) test
by Артем Лян (JIRA)
Артем Лян created TEIID-4958:
--------------------------------
Summary: test
Key: TEIID-4958
URL: https://issues.jboss.org/browse/TEIID-4958
Project: Teiid
Issue Type: Quality Risk
Components: Embedded
Reporter: Артем Лян
Assignee: Steven Hawkins
Priority: Trivial
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (TEIID-4957) Setting Connection Type on VDB of a Domain Managed server gets set back to default after server restart
by Debbie Steigner (JIRA)
Debbie Steigner created TEIID-4957:
--------------------------------------
Summary: Setting Connection Type on VDB of a Domain Managed server gets set back to default after server restart
Key: TEIID-4957
URL: https://issues.jboss.org/browse/TEIID-4957
Project: Teiid
Issue Type: Bug
Components: VDB
Affects Versions: 8.12.10.6_3
Reporter: Debbie Steigner
Assignee: Barry LaFond
After deploying a VDB to a managed server group, set the Connection type to anything but the default of By_Version, so None or Any. Now restart the server and you'll see the Connection type is reset to the default.
What I see is that when the change is made a vdb.xml with that new connection-type is written to the /DVserverhome/domain/servers/server-two/data/teiid-data/SampleVDB_1 folder, this folder is deleted upon a restart though so the change is not kept.
This only happens in Domain mode, running in Standalone mode saves the change because the teiid-data is not deleted on a restart.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (TEIID-4525) postgresql translator - remove all nulls & non printable characters
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4525?page=com.atlassian.jira.plugin... ]
Ramesh Reddy reassigned TEIID-4525:
-----------------------------------
Assignee: (was: Ramesh Reddy)
> postgresql translator - remove all nulls & non printable characters
> -------------------------------------------------------------------
>
> Key: TEIID-4525
> URL: https://issues.jboss.org/browse/TEIID-4525
> Project: Teiid
> Issue Type: Feature Request
> Components: JDBC Connector
> Reporter: Omar Khan
> Priority: Minor
> Fix For: Open To Community, 10.0
>
>
> Would like to see the postgresql translator enhanced to add a feature to minimum remove nulls from text strings as some other databases i.e. Teradata allow for them where Postgres does not. This feature would behave in a similar manner as TrimSpaces, but simply remove all \u0000 characters.
> Furthermore, if possible, would like the ability to remove non printable characters to as another option provide another additional stripping mechanism, allowing the postgresql database to serve as a data cleaner if need be.
> Please refer to https://developer.jboss.org/thread/272644 for details
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (TEIID-4525) postgresql translator - remove all nulls & non printable characters
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4525?page=com.atlassian.jira.plugin... ]
Ramesh Reddy reassigned TEIID-4525:
-----------------------------------
Assignee: Ramesh Reddy
> postgresql translator - remove all nulls & non printable characters
> -------------------------------------------------------------------
>
> Key: TEIID-4525
> URL: https://issues.jboss.org/browse/TEIID-4525
> Project: Teiid
> Issue Type: Feature Request
> Components: JDBC Connector
> Reporter: Omar Khan
> Assignee: Ramesh Reddy
> Priority: Minor
> Fix For: Open To Community, 10.0
>
>
> Would like to see the postgresql translator enhanced to add a feature to minimum remove nulls from text strings as some other databases i.e. Teradata allow for them where Postgres does not. This feature would behave in a similar manner as TrimSpaces, but simply remove all \u0000 characters.
> Furthermore, if possible, would like the ability to remove non printable characters to as another option provide another additional stripping mechanism, allowing the postgresql database to serve as a data cleaner if need be.
> Please refer to https://developer.jboss.org/thread/272644 for details
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (TEIID-4950) PostgreSQL Linux ODBC driver v09.06.0100 and newer does not work with Teiid Server 9.1.1
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4950?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4950:
-------------------------------------
[~scboyce] You may have wait until 9.3.1 or build from the master copy of it. No released version of it yet.
> PostgreSQL Linux ODBC driver v09.06.0100 and newer does not work with Teiid Server 9.1.1
> ----------------------------------------------------------------------------------------
>
> Key: TEIID-4950
> URL: https://issues.jboss.org/browse/TEIID-4950
> Project: Teiid
> Issue Type: Bug
> Components: ODBC
> Affects Versions: 9.1.1
> Environment: Oracle Linux 7.3
> OBIEE 12c
> unixODBC
> Official PostgreSQL ODBC Drivers
> Reporter: Steve Boyce
> Assignee: Steven Hawkins
> Fix For: 10.0, 9.3.1
>
>
> PostgreSQL ODBC driver v09.06.0100 and newer does not work with Teiid Server 9.1.1
> This is an OBIEE 12c/unixODBC error:
> {noformat}
> [2017-06-06T15:00:48.159+00:00] [OBIS] [ERROR:1] [] [] [ecid: 005KKjYVpflEkJ4_VTS4yc0004Vq0002Lh,0:1] [sik: ssi] [tid: a5dc9700] [nQSError: 16001] ODBC error state: 50000 code: 110 message: [unixODBC]ERROR: TEIID31100 Parsing error: Encountered "[*]SET[*] DateStyle =" at line 1, column 1. [[
> file: server/Query/Execution/DbGateway/Odbc35/../Odbc/Src/SQXDGOdbcConnection.cpp; line: 1009
> Properties: description=ExecutePhysical Exchange; producerID=0x321b5ff8; requestID=0x61ac0002; sessionID=0x61ac0000; userName=weblogic;
> Was expecting: "alter" | "begin" | "call" | "create" | "delete" | "drop" | "exec" | "execute" | "insert" | "merge" ....
> {noformat}
> Looking at the source code for the ODBC drivers, it seems that switching from CC_send_settings to CC_send_query for setting various settings does not work with Teiid.
> {noformat}
> # grep -r -i --include *.c DateStyle psqlodbc-09*
> psqlodbc-09.05.0400/connection.c: CC_send_settings(self, "SET DateStyle = 'ISO';SET extra_float_digits = 2");
> psqlodbc-09.06.0100/connection.c: res = CC_send_query(self, "SET DateStyle = 'ISO';SET extra_float_digits = 2;" ISOLATION_SHOW_QUERY, NULL, 0, NULL);
> psqlodbc-09.06.0200/connection.c: res = CC_send_query(self, "SET DateStyle = 'ISO';SET extra_float_digits = 2;" ISOLATION_SHOW_QUERY, NULL, 0, NULL);
> psqlodbc-09.06.0300/connection.c: res = CC_send_query(self, "SET DateStyle = 'ISO';SET extra_float_digits = 2;" ISOLATION_SHOW_QUERY, NULL, 0, NULL);
> psqlodbc-09.06.0310/connection.c: res = CC_send_query(self, "SET DateStyle = 'ISO';SET extra_float_digits = 2;" ISOLATION_SHOW_QUERY, NULL, 0, NULL);
> {noformat}
> I'm not sure if the bug is with the ODBC driver or this was an intentional change that Postgres Server can deal with and therefore Teiid server should be able to deal with.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (TEIID-4950) PostgreSQL Linux ODBC driver v09.06.0100 and newer does not work with Teiid Server 9.1.1
by Steve Boyce (JIRA)
[ https://issues.jboss.org/browse/TEIID-4950?page=com.atlassian.jira.plugin... ]
Steve Boyce commented on TEIID-4950:
------------------------------------
I have confirmed that the error still happens on Teiid v9.2.2.
I don't have a current version of 9.3.0 installed anywhere yet.
Can you be more specific to which version you think has been updated for this?
It will take some time for me to set up a v9.3.0 test server to continue testing.
> PostgreSQL Linux ODBC driver v09.06.0100 and newer does not work with Teiid Server 9.1.1
> ----------------------------------------------------------------------------------------
>
> Key: TEIID-4950
> URL: https://issues.jboss.org/browse/TEIID-4950
> Project: Teiid
> Issue Type: Bug
> Components: ODBC
> Affects Versions: 9.1.1
> Environment: Oracle Linux 7.3
> OBIEE 12c
> unixODBC
> Official PostgreSQL ODBC Drivers
> Reporter: Steve Boyce
> Assignee: Steven Hawkins
> Fix For: 10.0, 9.3.1
>
>
> PostgreSQL ODBC driver v09.06.0100 and newer does not work with Teiid Server 9.1.1
> This is an OBIEE 12c/unixODBC error:
> {noformat}
> [2017-06-06T15:00:48.159+00:00] [OBIS] [ERROR:1] [] [] [ecid: 005KKjYVpflEkJ4_VTS4yc0004Vq0002Lh,0:1] [sik: ssi] [tid: a5dc9700] [nQSError: 16001] ODBC error state: 50000 code: 110 message: [unixODBC]ERROR: TEIID31100 Parsing error: Encountered "[*]SET[*] DateStyle =" at line 1, column 1. [[
> file: server/Query/Execution/DbGateway/Odbc35/../Odbc/Src/SQXDGOdbcConnection.cpp; line: 1009
> Properties: description=ExecutePhysical Exchange; producerID=0x321b5ff8; requestID=0x61ac0002; sessionID=0x61ac0000; userName=weblogic;
> Was expecting: "alter" | "begin" | "call" | "create" | "delete" | "drop" | "exec" | "execute" | "insert" | "merge" ....
> {noformat}
> Looking at the source code for the ODBC drivers, it seems that switching from CC_send_settings to CC_send_query for setting various settings does not work with Teiid.
> {noformat}
> # grep -r -i --include *.c DateStyle psqlodbc-09*
> psqlodbc-09.05.0400/connection.c: CC_send_settings(self, "SET DateStyle = 'ISO';SET extra_float_digits = 2");
> psqlodbc-09.06.0100/connection.c: res = CC_send_query(self, "SET DateStyle = 'ISO';SET extra_float_digits = 2;" ISOLATION_SHOW_QUERY, NULL, 0, NULL);
> psqlodbc-09.06.0200/connection.c: res = CC_send_query(self, "SET DateStyle = 'ISO';SET extra_float_digits = 2;" ISOLATION_SHOW_QUERY, NULL, 0, NULL);
> psqlodbc-09.06.0300/connection.c: res = CC_send_query(self, "SET DateStyle = 'ISO';SET extra_float_digits = 2;" ISOLATION_SHOW_QUERY, NULL, 0, NULL);
> psqlodbc-09.06.0310/connection.c: res = CC_send_query(self, "SET DateStyle = 'ISO';SET extra_float_digits = 2;" ISOLATION_SHOW_QUERY, NULL, 0, NULL);
> {noformat}
> I'm not sure if the bug is with the ODBC driver or this was an intentional change that Postgres Server can deal with and therefore Teiid server should be able to deal with.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months