<@U04S8PLJWMT> I'm trying to use the Oracle connec...
# replication-ask-ai
j
@kapa.ai I'm trying to use the Oracle connector. I have a cursor modified_date of data type timestamp with time zone, example value "2012-02-28 123142.000 -0800". When I try to use this column as a cursor in my sync, I get error "Warning from source: Something went wrong in the connector. See the logs for more details. java.lang.RuntimeException: java.sql.SQLDataException: ORA-01843: not a valid month" - is there anything I can do here to get this to work?
k
The error
ORA-01843: not a valid month
is a Oracle SQL error that typically occurs when a date/timestamp string is being parsed with an incorrect format. This is related to how Airbyte's Oracle connector handles
TIMESTAMP WITH TIME ZONE
columns as cursor fields. Based on the knowledge sources, there are a few things worth noting: 1. Known limitation with
TIMESTAMP_WITH_TIMEZONE
as cursor
: There is a documented issue where
TIMESTAMP_WITH_TIMEZONE
columns are not fully supported as cursor fields in Airbyte's JDBC-based source connectors. A similar error has been reported for the Snowflake and Postgres connectors. [timestamp cursor error] 2. Data type mapping: According to the Oracle source connector documentation,
TIMESTAMP WITH TIME ZONE
is mapped to Airbyte's
timestamp with timezone
type (in the Enterprise connector) or
string
type (in the standard connector). [Oracle data type mapping] [Enterprise Oracle mapping] What you can do Recommended workaround: Use a different cursor column that avoids the
TIMESTAMP WITH TIME ZONE
type. Good alternatives include: • A plain
TIMESTAMP
column (without timezone) — this type is supported as a cursor in the Oracle connector. • An
INTEGER
or
NUMBER
column (e.g., a sequential ID or epoch-based integer). The test data in the Oracle connector's integration tests confirms that plain
TIMESTAMP
columns work as cursors, while
TIMESTAMP WITH TIME ZONE
handling has known parsing issues. [Oracle acceptance test] If you cannot change the cursor column, you could consider: • Creating a database view or computed column that casts
modified_date
to a plain
TIMESTAMP
(stripping the timezone), and using that as your cursor instead. • Checking whether you are using the Enterprise Oracle connector, which has more complete type support, and upgrading if applicable. Unfortunately, the knowledge sources do not contain a direct fix or confirmed resolution for this specific
ORA-01843
error with the standard Oracle connector, so I'd recommend opening a GitHub issue or reaching out via the Airbyte Community Slack for further assistance. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
The error
ORA-01843: not a valid month
is a known type of issue with timestamp-with-timezone columns being used as cursor fields in Airbyte's Oracle connector. Based on the knowledge sources available, here's what I can tell you: What's happening The Oracle source connector maps
TIMESTAMP WITH TIME ZONE
to a
timestamp with timezone
Airbyte type [Oracle data type mapping], but there are known issues across several Airbyte JDBC-based connectors where the cursor parsing logic cannot correctly handle timezone-aware timestamp formats when building incremental sync queries. Similar bugs have been documented for: • Snowflake:
TIMESTAMP_WITH_TIMEZONE
columns throw
Unsupported cursor type
[timestamp cursor error] • Redshift:
timestamptz
columns cause
DateTimeParseException
because the parser doesn't handle the
Z
timezone suffix [Redshift timestamp parse failure] Your Oracle error (
ORA-01843: not a valid month
) suggests the connector is likely passing a malformed timestamp string back to Oracle when constructing the incremental cursor query — possibly because the serialized timezone-aware value (e.g.,
2012-02-28 12:31:42.000 -0800
) isn't being parsed and re-formatted correctly before being sent to Oracle. What you can do The knowledge sources do not contain a confirmed fix specifically for the Oracle connector and this exact error. However, based on the workarounds documented for similar issues in other connectors, you can try: 1. Use a different cursor column — If your table has a plain
TIMESTAMP
(without timezone) or an integer/sequence column, use that as the cursor instead. This is the most reliable workaround while the underlying issue exists. [timestamp cursor error] 2. Check your Airbyte and connector version — Ensure you're on the latest version of the Oracle source connector, as fixes for related timestamp parsing issues have been released for other connectors (e.g., Postgres, Redshift). [Redshift fix PR] 3. Report the issue — If the problem persists on the latest version, consider opening a GitHub issue at airbytehq/airbyte with your connector version, the exact error, and the timestamp format. This helps the engineering team prioritize a fix. I'm sorry I can't point to a direct fix for the Oracle connector specifically — the knowledge sources don't contain enough detail about this exact error path in the Oracle source code to confirm a resolution. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.