DSXchange

pavithravenky wrote:How to read the xml files dynamically and convert it to a csv files without any xsd defined?

Why "dynamically"? You'll need an xsd for each of these if you want to use the new XML stages, are you saying you don't have them or for some reason cannot get them?

So what is your actual problem? All you've mentioned is this port you "can't see" but how is that manifesting, specifically what is not working for you?

sanygup wrote:Server was working fine earlier when firewal was not used although as i mentioned i have opened all the required ports for datastage.

Then it would seem that you did not in fact open all of the required ports. Can you list exactly what ports you opened?

Best to ask your official support provider. That version is too dang new and restricted to a DB2 repository for now so not much experience with it out in the wild, I would imagine.

Sure... but to come back to the original question at hand, the answer is still no. Unless someone has some experience to the contrary?

It really... depends. What does your "default" value represent - the lack of a date, the beginning of time, the end of time, something else entirely? I've seen anything from 01/01/0001 to 01/01/1900 to 12/31/9999 and various values in between used. Typically this would be something defined...

It won't need to be recompiled.

A couple of questions. Is this a Server Shared Container in a Parallel job? And is this behavior repeatable, meaning does it always produce no output from the aggregator.

I'll say one thing, we can certainly be... quicker... at times. Been there, done that, got the t-shirt kind of stuff.

Array size = how many records are sent over the network to the database at a time. Transaction size = controls commit in the target database based on row count. Setting both to 1 would guarantee the slowest load possible. :wink: When you pick new numbers, make sure the transaction size is an even mu...

A2: No.

A3: Too many variables for a generic answer and most are dependent on your data and hardware. You might want to discuss that with your SQL Server DBA and see if they can help. Do you understand what they control?

You are NOT mistaken. :wink: Q2: Not quite sure... what would you use another hashed file for? Q3: A hashed file will easily handle that load. Best to set the initial size (Minimum Modulus) to something large so it doesn't immediately start to extend and fragment. If it takes 'too long' to build or ...

Suggestion: drop this issue for now and start a discussion on the "dropped at insert time" problem. Come back here if resolving that one doesn't solve this one at the same time.

Ok... but didn't really answer my question. Does resolving this require solving any of the issues noted or is this just about you wanting to remove the warnings?

Hvve you considered using a hashed file to cache the lookup data rather than reading directly from the database? They are the heart and soul of Server jobs, after all. The 'trick' is to load into them only what you need for each job run which typically involves joining the incoming keys to that data...