<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