DSXchange

You still have to set the date format string in your metadata to "%yyyy%mm%dd" - you have provided no evidence that you have done so.

No more server job stage types of which I'm aware.

Somehow you need a list of table names. You may be able to read it using a simple command (rather than a script). Maybe you can even hard-code it in the StartLoop activity. Use a "list of things" loop in the StartLoop activity to step through your list.

There must be at least one other stage (a server job must have at least two). I suspect that the other stage is a DRS stage set to connect to Oracle (hence the drsoci reference in the error message). You have to make sure that the parent directory of drsoci.so is in your shared library search list (...

ODBC does not handle unbounded VarChar or Long VarChar. Prescribe a maximum length in the Precision column.

This is not a DataStage issue; it turns on the SQL grammar for ODBC.

Your default date format is ten characters (YYYY-MM-DD) but the dates in your data contain only eight characters (YYYYYMMDD). You need to adjust your metadata, specifically the format for that date column.

The second paragraph of Craig's post tells you what you need to do.

You can get the set of keys from the source data. The keys would ordinarily be indexed in the target so the cost of the deletes will be small.

jdinero wrote:I was told by IBM that certain functions behave different from 8.7 and 9.1.

Can you get any more information about these? It's a terribly vague assertion not really backed up by "what's new in this release" documentation.

You can compare ONE job across projects. There is no tool that will do them all. Some will suggest exporting the jobs from each project and comparing the DSX files with a command such as diff.

It would be. Each row generates a DELETE followed by an INSERT.

You need a different strategy, for example gather the keys of the affected rows and create a job that runs simple DELETE. Then run INSERT or UPDATE in a second job.

Welcome aboard. This is not really an ETL task, but you can readily use stage variables in a Transformer stage to keep track of the previous row's value(s) in order to effect your comparison(s). Another stage variable can be used to monitor your "first to last" (begin true, set to false on...

Read the entire record as a single VarChar and parse it within the Transformer stage. Use stage variables to detect the arrival of a new parent and to accumulate the output record. Use a downstream RemoveDuplicates stage to preserve the last of each group (with the same parent record). You didn't me...

Have you tried running four Standardization stages, passing the unhandled data from each to the next, perhaps adding in the postcode and state ahead of the second AUAREA standardization?

That's truncation before loading. I tried to answer the question about truncation after loading - unfortunately perhaps one can not make the After SQL in a Connector conditional. Therefore, unless you can determine a means in SQL of determining that the load failed, you will not have a solution &quo...