Try sending the date into the writer formatted as an FME datetime

I guess it's the same issue as this Q&A;: Problems to write field date in Postgis Database

Hi,

Thanks for the immediate answers.

Unfortunately this doesn't solve. I will continue with formatting.

In the meantime, waiting to solve, I will use sqlExecutor.

In your experience, which is the impact in terms of performances, writing/updating/deleting approx 3000 records every 3 minutes?

Is the writer faster (I think so) than multiple SqlExecutors?

Sorry for the question based on my reduced know-how on the product.

Thanks

Regards

Roberto

You could also solve this on the Oracle side, by creating a trigger on the table:

CREATE OR REPLACE TRIGGER trigger_name

BEFORE INSERT
ON table_name

FOR EACH ROW

BEGIN

IF ::NEW.CREATEDTIME IS NUll Then

::NEW.CREATEDTIME := Sysdate;

END IF;

END;

I tried to reproduce issues... But couldn't with what I know so far.  What version of FME are you using?

Here's what my attempt looked lie: 

I created a table in Oracle:

CREATE TABLE SM_TEST_DATE2  (   ID1 NUMBER  , MYCOMMENT VARCHAR2(50)  , MYDATE TIMESTAMP WITH TIME ZONE );

Then I imported the feature type into FME 2018.1.  From there I created a simple workspace and added the DateTimeStamper and set the UTC Offset to yes. This created a record in the table.  

However, if I didn't set the "UTC Offset" to "Yes" I got this error in 2018.1:

20180910151849.323846' is not an FME datetime. YYYYMMDD, HHMMSSt.X+]�(+/-)zz] or YYYYMMDDHHMMSS>.X+]e(+/-)zz] expected. Use a DateFormatter transformer to adjust the format of datetime strings.

In this image, you can see the error in the translation log.  Note that the transformer parameters in this image are correct and will create a valid timestamp for data type "TIMESTAMP with TIME ZONE" in FME 2018.1.

Also, I did notice that if the UTC Offset was No, a record was still created in the table but the Date attribute (MYDATE) was NULL.  This matches what you are reporting.

Hope this helps.