Обсуждение: pentaho timestamp issue

Поиск
Список
Период
Сортировка

pentaho timestamp issue

От
PropAAS DBA
Дата:

Pinging the list on the off chance someone has dealt with this and knows of a workaroud. We have pentaho pointing to a PostgreSQL v10.3 database, getting this error:


2018/03/18 15:06:37 - INPUT STEP - Fact.0 - Timestamp : Unable to get timestamp from resultset at index 55

2018/03/18 15:06:37 - INPUT STEP -  Fact.0 - Bad value for type timestamp : 0001-02-04 17:00:04-06:59:56

2018/03/18 15:06:37 - INPUT STEP -  Fact.0 -

2018/03/18 15:06:37 - INPUT STEP -  Fact.0 -

2018/03/18 15:06:37 - INPUT STEP -  Fact.0 -           at org.pentaho.di.core.database.Database.getRow(Database.java:2302)

2018/03/18 15:06:37 - INPUT STEP -  Fact.0 -           at org.pentaho.di.core.database.Database.getRow(Database.java:2270)

2018/03/18 15:06:37 - INPUT STEP -  Fact.0 -           at org.pentaho.di.trans.steps.tableinput.TableInput.processRow(TableInput.java:153)

2018/03/18 15:06:37 - INPUT STEP -  Fact.0 -           at org.pentaho.di.trans.step.RunThread.run(RunThread.java:60)

2018/03/18 15:06:37 - INPUT STEP -  Fact.0 -           at java.lang.Thread.run(Unknown Source)

2018/03/18 15:06:37 - INPUT STEP -  Fact.0 - Caused by: org.pentaho.di.core.exception.KettleDatabaseException:

2018/03/18 15:06:37 - INPUT STEP -  Fact.0 - Timestamp : Unable to get timestamp from resultset at index 55

2018/03/18 15:06:37 - INPUT STEP -  Fact.0 - Bad value for type timestamp : 0001-02-04 17:00:04-06:59:56



I've done some looking and this is clearly not a PostgreSQL issue, but maybe there is an easy workaround?    Anyone have any thoughts...


Thanks in advance

Re: pentaho timestamp issue

От
Tom Lane
Дата:
PropAAS DBA <dba@propaas.com> writes:
> Pinging the list on the off chance someone has dealt with this and knows 
> of a workaroud. We have pentaho pointing to a PostgreSQL v10.3 database, 
> getting this error:
> 2018/03/18 15:06:37 - INPUT STEP -  Fact.0 - Bad value for type 
> timestamp : 0001-02-04 17:00:04-06:59:56

Hmm.  Presumably, this is coming from something that thinks that 1 AD
is outside the reasonable range of timestamps.  Assuming you agree that
such a value shouldn't appear in your application, I'd look for timestamps
getting put into the database using to_timestamp() with a format string
that doesn't really match the data, causing the year field to be truncated
or misinterpreted.

            regards, tom lane