Getting Data In

Trouble with DB2 timestamp.

keithkelley1
Engager

Ive added a new database connection to DB connect. My first actually. the dbx.log has the following message associated with the rows that are being processed.

2014-01-03 20:12:43.640 dbx1434:WARN:ResultSetOutputPayload - Unrecognized timestamp format: '2013-12-08 21:41:17.000'

I have tried various items suggested on the forum but, it does not seem to go away.

Tags (1)

btsay_splunk
Splunk Employee
Splunk Employee

you may configure the timestamp format for this dbmon/dbtail/dbdump?

The timestamp format expressed as a Java SimpleDateFormat pattern. The default format is configured in the Splunk DB Connect app setup.

0 Karma

araitz
Splunk Employee
Splunk Employee

Can you share your configuration for the input? Alternatively, you can open a support case and submit a diag.

0 Karma

keithkelley1
Engager

it looks like the warning is being logged when the data is indexed. Data is getting indexed but not with the preferred date/time stamp that would make it usefule.

0 Karma

araitz
Splunk Employee
Splunk Employee

Is the problem just that the warning is being logged, or is the data not being indexed as expected?

0 Karma
Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

From Data to Insight: Announcing the Winners of the Splunk Dashboard Contest

Hi Splunkers, First off, thank you to everyone who participated in our very first From Data to Insight: The ...

Splunk Developers: Construct Your Future at the .conf26 Builder Bar

Calling all Splunk architects, platform admins, and app developers: the site is open, and the blueprints are ...

Quick connection discovery mode for forwarders

When a Splunk forwarder loses connectivity to its indexers, it does not always reconnect immediately. In many ...