DSXchange

Stage Variables can hold the 'previous' values of things so you can use them against the next row that comes along. It's all about declaring them in the proper order. There's a Tech Tip in this zip file that explains how to do group change detection with stage variables. The technique will also work...

If your process created the hashed file, it should write the max value out and use a column with a literal key value, maybe something like "FRED". <snip> When your job references this hashed file, just put "FRED" in the key expression for the lookup. The same row will be found over and over and ove...

Nope.

Sure, they all go into a single log, but they are identified by Invocation ID. Director can show them as 'separate logs' and you can treat them like same. Instead of using jobname with the dsjob command, using jobname.invocationid should do the trick. Or are you looking for something other than that...

Don't worry about it, at least you seem to be trying to figure it out on your own. Sometimes people don't even do that much.

Keep at it and if you have more questions, post them.

As far as I know, it doesn't even use the PATH variable for things like that. As a matter of fact, I've got nothing in the way of Oracle in my PATH statement and it works just fine. It's all about the Shared Library...

I'm assuming 'I am no able' actually means 'I am now able'.

Care to share any words of wisdom, what worked for you, things that would help a fellow searcher who had the same problem and found your post?

What do you mean by 'the same path' that worked before you installed ODBC drivers? Are you saying that you could import plug-in metadata via the OCI stages before but can't now? Or never could? I don't see anything wrong with your dsenv off the bat, are you sure your ORACLE_HOME is being set correct...

It might be best to say why you think you need this and then alternatives can be proposed. Like... using dsjob from the command line with the -run -mode RESET options. Otherwise, from a routine - by getting a handle on the job and then using that handle to issue a DSPrepareJob on it. Then dettaching...

Sure, just create a job that looks like it inserts data into the table, but don't actually send anything. Simplest to do this with a job that starts from a Transformer. 1) Create a dummy stage variable in the Transformer. 2) Set the constraint to @FALSE. 3) Include all the columns and set their deri...

Yes please! :D

thompsonp wrote:Out of interest what is Lakh as in '2.5 Lakh records'?

It's a unit of measure equal to 100,000. 100 Lakh = 1 Crore, btw.

I'm in the same boat, haven't touched it for years. Curious what comes of all this.

If you search the forum, I do believe you'll find that DB2 wants any date fields in internal format... I wonder if the same is true for timestamps?

bhaskarjha wrote:i also tried with "timestamp.to.date(sourcecoulmn[1,19])" but its then rejects the row

That looks like a PX derivation, you sure your Job Type is 'Server'?