DSXchange

We already have topics on that from SPuneet. They seem to be experimenting as we keep seeing basically the same set of incoming data with different requirements and techniques posted. We've already done aggregator and transformer solutions, guess it's now time for sorting and Remove Duplicates. :wink:

Just to get anal and all nit-pick-itty, one cannot only 'read' certain records from a sequential file. It's called that for a reason and records from sequential media must be read from beginning to end, it's the nature of the beast. You may only want to process certain ones, which means via a contra...

There wouldn't be an "special setup" involved so best to take that question to your official support provider as it does sound like it could be a bug in the connector.

First, last, who can keep track?

Or run fewer jobs at the same time...

Simpler version...

If sv_ID is null and In.ID is not null then In.ID else sv_ID

You shouldn't need to worry about the row number if the initial value is set appropriately, never mind the fact that you'd have to be very careful with it when running on multiple nodes.

The stage variables route would be pretty straight-forward. Setup one for each column and just do an if-then-else check to say if your SV is at its initial value and the column is non-null store the column value otherwise do nothing... and you do 'nothing' by setting the stage variable to itself, it...

Pretty simple to push things to the database side when everything is in the same instance but if you're saying that these are two separate instances then the data still has to come out of one and travel across something to get to the other. It might help to explain your topography in more detail. Ot...

What 8.x version do you have? Normally the aggregator would help out for something like this but I don't think it is a viable option here due to needing the first value rather than say the max value. The Server aggregator supports first/last but I don't believe the parallel one does. Failing that, i...

No. You could connect to one and access the other over a dblink, I suppose. Why this odd "requirement"? You need to do what across "two Oracle servers"?

Ok, so a positive zero then.

I really have no idea what might be going on but wanted to point out that "123}" isn't any kind of proper signed conversion of "1234"... which I'm sure you know. That "}" is a "negative zero" whereas you should have a "D" there.

Pretty sure you can specify the character to trim, spaces is just the default. Convert would work for this as well.

Check again. The first (second?) log entry shows the values of all parameters in effect when the job started and off the top of my head you should see those encrypted values there. I've got no way to check or confirm...

From the logs.