DSXchange

Something like this; the Lookup determines whether the row (key) already exists in the table (possibly against a key-only Data Set) and, on that basis, either sends the row to be inserted (insert only) or to be updated (update only). -----> Lookup -----> Insert -----> Update

Good feedback, thanks.

Is someone going to report this anomaly (and problem) via their support provider? If so can you please post their response here?

You can only import stored procedure definitions where the stored procedure deals with a "result set" - that is, rows of data.

Apparently the import process can find no such stored procedures in your data source.

How about containing the job parameter reference in "#" characters?

I'd suspect RCP as the culprit, magically reinstating SOURCE_CRNC_CODE because it's in the schema somewhere.

According to the manual (Parallel Job Developer's Guide, page 27-6 for version 7.0) the conversion is handled automatically.

You could work indirectly, via decimal_from_string().

It may be easier, though, to create a message handler to demote this warning to an informational message.

Welcome aboard. :D

Have you reported this deficiency through your support provider? It seems an obvious thing to want to do.

Further, named pipes shouldn't get all that large, since there should be a process draining them as fast as the process that is filling them. But, if your /tmp file system is small (as is often the case on Solaris systems particularly) you would do well to point TMPDIR to a file system with lots of ...

Yes, the "Windows solution" (re-boot) is probably best, because you can't do anything else with DataStage (apart from re-install) until you can get the Resource service started.

Once you've got it started, then checking your projects as Arnd suggested is probably a good idea.

If you edit the table definition that you imported, you will find that the physical column width is stored as Display Width. Or you can use the Edit Row facility to specify the column widths explicitly.

Oracle does have stored procedures.

Not really, because I have no idea what you want to do. By "local variables" I mean, of course, stage variables in a Transformer stage. And expressions, well these might be stage variable initialization expressions, stage variable derivation expressions, output link constraint expressions or output ...

Interesting.

Have you tried thwarting Oracle in the SQL? For example

In a PX job, If data is partitioned on key 1 and then aggregated on key 2, what issues could arise? Thx VS Are you sorting on key 2? If not, the Aggregator stage will use a lot more memory than otherwise. Partitioning on other than key2 may mean that some key2 values are on node 1 and some key2 val...

It occurred to me to take a short vacation from posting when on about 9998 posts, just to thwart the bookmakers and gamblers.