DSXchange

Just looking at the row counts ("performance statistics") in Designer will give you a clue. If there are row counts both sides of the Copy stage, then it's in the design and in the runtime.

Use RAWTOHEX function in your SELECT statement.

imfarhan wrote:But , the connection was made successfully last week. and today same error and I haven't change anything since last week.

Something has changed since last week. You have to do some detective work to find out what it is, particularly if it was not you who made the change.

Definitely badly formed. Solution is to have "them" provide well-formed data records.

If the only change is SQL Server, that's where you need to look - either to the SQL Server instance itself or to the network connectivity to it (are you taking 24 hops?). How is the new different from the old?

Do some study about UNIX pipelining. You don't want the | operator here. As Craig notes, you may not need any operator. But, if you do want to pipeline two commands other operators exist, including ; && ||

Or you could use a DataStage job (not sequence) using an FTP stage.

I don't know. However you can research this yourself. Source code for dsjob lives - if I recall correctly - in the sample directory under $DSHOME.

Have you read the manual, on-line help or Information Center articles on configuring DSODB? All three tell you precisely where to find this configuration setting.

Resist stupid requrements!

If you could do every transfer with the same DataStage job, there wouldn't be much work around, would there? There will be occasional differences (for example different databases' ways of handling BLOBs) that will require variations on your theme.

It won't make a whole lot of difference, because (unless very, very wide) the entire row is read and written when an UPDATE is performed. Indeed, it is the page containing the row that is read and written.

Your example is a badly-formed CSV record, in that it has an odd number of quote characters. How many fields is it supposed to have? Once you have this sorted you, probably the best solution is to use a server Sequential File stage (possibly in a server Shared Container in your parallel job), which ...

Yes and no. According to the specification in your original post you also have to undertake some kind of checking/processing against the FIRST_RECHARGE table. Your more recent post on this thread seems to omit this requirement altogether.

You have a couple of choices, effectively the same logically. Perform a lookup against first recharge table with Lookup Failed rule set to Continue, then test in a downstream Transformer stage whether the columns returned from the reference input are NULL. Or perform a left outer join, with recharge...

Yes. Use whatever you get when importing the table definition using the Connector Access Wizard.

Do you mean new in the stream of data or new in the database to which you're writing? (Tip: learn to write clear specifications - it will help any career to which you might aspire in IT.) In the first case sort the stream and generate a key change column. In the latter case, perform a lookup and set...