Re: Postgresql ODBC Truncates Timestamp second fractions
От | pg_gg@mailinator.com |
---|---|
Тема | Re: Postgresql ODBC Truncates Timestamp second fractions |
Дата | |
Msg-id | E1WWeqB-00018c-LR@free.hostodon.me обсуждение исходный текст |
Ответ на | Postgresql ODBC Truncates Timestamp second fractions (pg_gg@mailinator.com) |
Ответы |
Re: Postgresql ODBC Truncates Timestamp second fractions
|
Список | pgsql-odbc |
<p>We have started with Oracle, but most probably they won't do much about it as their ODBC driver handles timestamps properly,but not the Unicode null character, which they have documented as a limitation, so it's hard to press them on that.<p>Wewere hoping to make it work by using the official PG ODBC driver, and this driver although handles the problemof null character, has the problem with timestamps.<p>Unfortunately I don't think I'm getting relevant answer to myquestion which is where we should look into the code to find out how the PG ODBC driver handles paramter conversion andspecifically SQLDescribeParam and SQLBindParameter funnction calls.<p>Thanks anyway for your help.<p>On 04/05/2014 05:15PM, pg_gg@mailinator.com wrote:<br /> > I don't think the problem is only with the OGG. My understanding is that<br/> > OGG polls the destination metadata first and then describes and prepares<br /> > the parameters and theSQL statement based on the metadata. Either OGG<br /> > interprets what it receives from PG differently than othertools, or the<br /> > driver behaves differently for OGG, and that's what we are trying to<br /> > understandbased on the code. Just don't know where to look.<br /><br /> I would say, start with Oracle, it is their product.I am going to<br /> assume support is part of the package. or am I wrong?<br /><br /> There is some evidence it doestreat things differently:<br /><br /><a href="http://docs.oracle.com/cd/E35209_01/doc.1121/e29642.pdf" target="_other">http://docs.oracle.com/cd/E35209_01/doc.1121/e29642.pdf</a><br/><br /> "timestamptz data type<br /> PostgreSQL<br/> timestamp with timezone<br /> column type is recognized as<br /> SQL_VARCHAR<br /> and therefore<br /> OracleGoldenGate writes the data in the native<br /> format of the source<br /> database, rather than<br /> normalizing itto its PostgreSQL form. As a<br /> result, some replicated timestamp data might<br /> not be compatible with Oracle GoldenGatecolumn-conversion functions and<br /> FILTER<br /> clauses."<br /><br /> ><br /> > Also the DataDirect ODBConly handles timestamps when it's defined<br /> > without a percision in which case the metadata query returns -1for the<br /> > field lenght. If precision is defined, even if it's 6 then it fails with<br /> > the error mentionedin the link below and we would need to set the<br /> > WorkArounds2=2. But that doesn't solve the problem becausethen it nags<br /> > about data overflowing. So the only way to make the Data Driect drive to<br /> > work isto not define the precision, but as I mentioned before, that<br /> > driver doesn't handle Unicode null character, sowe can't really use it.<br /> ><br /><br /><br /><br /> --<br /> Adrian Klaver<br /> adrian.klaver@aklaver.com
В списке pgsql-odbc по дате отправления: