DSXchange

You didn't specify a database, so...

If I run the job again, the runs very slow. I haven't been able to run an Update. I created a primary indexed key on the Oracle table and I still get the same problem. You'd need an index on whatever Key field(s) control what gets updated, otherwise what you are waiting on is a full table scan for ...

Mostly by taking cheap shots at my friends.

Hopefully someone CDC savvy will wander along and give you a real answer RSN.

crouse wrote:Am I missing something?

Undoubtedly... but then again, par for the course.

Automatically? Nope.

Again, please post the actual values from the log, not from the job. It should have all those parameters translated and show exactly what was actually run.

Post your command syntax, not Ray's. And I mean the actual 'Executed command' from the same log entry you posted the output from.

No, it doesn't - and it's not one I've seen before.

Suggest you open a ticket with your official Support provider, get some professional help tracking that down.

If you remove that one 160MB file from the directory, does the job run to completion?

Reset the Aborted job and let us know if a 'From previous run...' message is added to your log. If so, double-click on it and post the contents.

Timestamp datatype all the way through? Generated sql at both ends?

You can't - at least not directly. You can, however, use 'dsjob' at the O/S level to accomplish that.

Are you looking at the XMLPACK_20_Designer.pdf manual? If that truly doesn't match with what you have installed then I'd say you still have the 1.0 release of the XML PACK installed somehow. As for other resources, check Kim Duke's tips page where, if you scroll down near the bottom, you'll find an ...

Check your teammate's thread.

Make sure the field is a Timestamp in the target stage as well and the stage generates the sql. Then it will do a matching TO_DATE() on your data with the same mask the TO_CHAR() used to select the data: YYYY-MM-DD HH24:MI:SS. Don't "use substrings on the field to get the date and time individually"...

No, it was pretty clear the first time and not something all that unusual around here as issues handling Oracle DATE fields aren't all that uncommon. Well, except for the DS_NO_FF thing, never heard of it and have no clue that 'FF' would stand for. You really shouldn't have any problems with Oracle ...