DSXchange

Search really helps. Try this for instance.

Welcome Aboard
Do an exact search on keywords "Unrecognized top level format property".

I believe you can if it has only IN or INOUT paramters. Never tried it myself but the only limitation for calling odbc stored procedures is that it only supports IN and IN OUT parameters.

Dont have to go through all that, just load your files into a two different tables in a schema and write sql to do it. It will be much easier.

Thanks Craig for jumping in and brining into attention a very important point that I failed to mention.

Craig wrote:They then become available for further processing if you disable caching of the hashed file lookup or if you choose 'Enabled, locked for updates'. The former is generally safer

pp wrote:Is it so that datastage adds this space for a signed value ?

Welcome Aboard
There you go, you have the answer right there. If you have to trim the space you need to convert it to varchar using DecimalToString() and then apply the trim to it.

Its complaining that you have defined it as ustring? What is the datatype, set it as timestamp or Date with length 38. The sql select will automatically stick in a TO_CHAR() to it.

Making it work is one thing and a supported platform is another. At IBM's website they are a matrix chart which has all information about supported platforms.

Do a lookup against the hashed file that contains data from table XYZ and load into the same hashed file. This way the hashed file will be updated and looked upon at the same time. Finally load that hashed file into your table XYZ.

You need to have dynamic names for all files you use in multiple instance jobs. Having that said, its better if you create the file in one job and outside a multiple instance job.

dsisbank wrote:I didn't understand how I get the previous values in transformer...

Its the order of execution. The stage variables are executed in the order they are defined so the last variable will have the previous rows value by the time the first stage variable is being executed for the current row.

videsh77 wrote:But I have seen the column information is getting wrapped. How to avoid this wrapping of column info?

What do you mean by that? Do you mean the column name, thats just first two lines, you can delete the first two lines.

How many keys are you going to be joining on?

Someone or some program killed your process. Try to find out what happened.

O thats fine. Just wanted to throw in my 2 cents by letting you know that such a thing is possible with enterprise schedulers.