DSXchange

Some progress has been made. Since LOGTO UV did not generate the error we know that there is no problem with the LOGTO command, so the read operation failure is in the EDWPROD "account" (project). There is no read operation in the automatically executed LOGIN item (which is why I wanted to...

No, you can do it with a job. A server job is probably the more efficient since only one row is to be processed.

What is the hex equivalent, under your business rules, of 3.141592818 ?

It's easy enough to convert unsigned integers to hexadecimal equivalents, but your question was about (signed?) decimal numbers.

Welcome aboard. The short answer is that it does not. You create a job to initialize the next key value by effecting a SELECT against the table.

And it contains the only accurate guide to where the data files of the Data Set are stored. So, if someone has deleted it, you need to get it back from somewhere. And castigate them severely!

throbinson wrote:Why would Datastage do that? Why DECIMAL(38,10)? I do not know.

Because that's what Oracle reports when any client tool retrieves the table definition using SQLColumnAttributes() function and the Oracle column is of unqualified type NUMBER.

Restore the *.ds file from backup and delete the Data Set properly.

If you don't have a backup then shame on you.

Create a new stage type (of type Build). Add code. Compile.

It may be that the forced closure of the hashed file (by UVFIXFILE) has re-synchronized the hashed file header and the in-memory copy - the item that was causing the "load imbalance" to be detected. But I still can't see how this (UVFIXFILE in trace mode) would interfere with successful st...

It would point somewhere else.

Without your providing the actual statement there's not much we can add to that statement of the bleeding obvious.

You may need to apply a conversion, changing the fractional part of the seconds from .6 to .3 in the timestamp format picture. This may be possible in a Modify stage (I've not tried that). It is definitely possible in a Transformer stage.

Are you running version 7.5? If so, is there an icon on the toolbar, an icon that looks like the Internet Explorer icon? This will generate your documentation in HTML format, complete with bitmap picture of the job design. You can achieve the same thing with the -report option of the dsjob command.

Any SQL-based lookup will be slower than hashed file lookup.

Greater speed can be had if the columns mentioned in the WHERE clause are indexed; without that you are potentially performing a full table scan for each row processed.

In DataStage server, in which all data are treated as character strings, S9(5)V99 requires nine character positions, not seven; one for the sign character, seven for the digits and one for the decimal placeholder character. Similarly, S9(5) requires six character positions; one for the sign and five...

Don't forget the essential set to execute the $DSHOME/dsenv script first.