DSXchange

Chulett, I like to know how can I do this one stage,probably based one your question or answer I can explain your more. That's the easy part of all this. Whenever you are working with two target tables, as long as they are in the same database and can be accessed by the same user, you can use a sin...

Well, one such way would be to edit the .dsx file and change all occurances of Readonly "1" to Readonly "0" before importing.

Mike wrote:Try making the commit interval 1 in the stage doing the deletes.

Or use a single stage.

I've had the problem here with HP-UX. Definitely saw it under 7.0.1, not sure I've checked again with 7.5.1A.

Be aware that - depending on your version and platform - they may not work. It can be confusing as heck to debug because the command will log correctly with the parameters fully expanded, but the actual command executed will still have the 'unexpanded' parameter name(s) in it.

Test it first.

Check this post for a downloadable Tech Tip that will explain how to do this. It includes pictures of the job and stage variables design, which can really help bring the methodology across. Picture. 1000 words. You know.

lstsaur wrote:Oracle does not have a timestamp datatype.

Oracle has a TIMESTAMP datatype. Been there since 9i, I do believe.

How are you trying to insert it? What is the target Oracle datatype? Details, man, details!

You could take an empty log and copy the files from there over to the directory where the files were removed. That should give you normal access to things again.

Locked is a whole 'nuther issue. Search the forum for UNLOCK for various discussions on handling locked jobs.

No - you need to "explain more in detail" as it's obvious we here are not sure what one of the many dredged up possibilities it might be.

Can you tell us what it stands for? Can you provide a reference on the net (or elsewhere) where you saw it used? That might help...

nekkalapudi wrote:I also has a Julian date YYYYDDD (2006207) need to be converted to regular date (YYYYMMDD)

Can't help with the other, but just wanted to be be picky and say that what you've got is an Ordinal Date, not a Julian Date.

Sure, it's possible - just completely unnecessary.

If you do it, make sure you use the right format mask on the target side. Or the dangerous practice of using a varchar and matching the default date format for your target. It may work, but is a Very Bad Practice as far as I'm concerned.

You don't need to 'convert' anything. Simply declare the datatype for the Oracle DATE field as Timestamp on both source and target, let the stages generate the sql and you'll be fine.

Or perhaps you should contact Technical Support. Sounds like one of those 'unexpected as it should never happen' kind of error.

From this calendar table you allegedly have in DB2. Select only the bad dates from it. Any calendar worth its salt should have indicators you can use to constrain your query to just those dates.