DSXchange

While loading check the network traffic.
Also, what action are you performing on the table?
1500 rows/sec may be good for someone else's case but not for you, depending upon your record size, action performed etc. etc.

Is there a message file that the load utility creates? Look into that for more messages.
Also you can ask your dba to monitor the database while you load.

No No, you got me wrong. First you were selecting from D1.T1 and loading to D2.T2 in the same job. Then you created a new job that selects from D1.T1 and loads to a sequential file which took 5 mins or so. Create another job that loads the sequential file to D2.T2 to see how much that takes. Basical...

Your J1 will load the records to a flat file. Build another job that loads this flat file to your D2.T2
See how much time that takes.

Welcome Aboard
Look at the date and time parallel function DaysSinceFromDate in datastage help.

Use simple logical operators >,<,= etc. Also for date comparisons, either convert it in YYYY-MM-DD format or to internal format.

If you run that sql from your favourite sql tool, does it work?
From a glance, it seems like the warning is due to the fact that your trying to fit a 38 length field in a 31 length field. Runt he same query from TOAD or sql developer and see if you get a smooth query.

Or just turn on inter process buffering from the job properties.

I confirmed it with my DBA. We do have 64bit SQL Server 2005. The driver we are using is DataDirect 5.0
I connect to it, no problem.

What if you load it as varchar? Run a test on a table using the load method which does not have timestamp in it. Is it really a timestamp issue? All that the error says is that the record is larger than the fixed length. We dont know for sure it really is a timestamp issue.

In the first job itself load a hashed file with a dummy key with the job start time. Reference that hashed file in the derivation of a parameter using UtilityHashLookup(), in all the following jobs.

I connect to SQL Server 2005, just need to check if its 64 bit. Can't do that untill tomorrow. But there is an option, something to the effect "SQLServer 2000 compatable", make sure you have that enabled.

# ********************************************************************************************************** # *** This section creates ABORT condition in Maestro when either Vality or DataStage failed . ************* if $clean=N then echo !!!!!! Vality step FAILED !!!!!! rm GoodJob.txt fi if [! -e...

NUMBER with precision will accept decimal. Without precision will just be an integer.

Ill highlight Craig's suggestion, SCALE. Fix the scale.