DSXchange

Post your SQL please.

The only way to identify the issues are to eliminate as many issues as possible. When your client is particularly sluggish, look at system utilization using something like top, prstat, or glance on the repository node. Maybe jobs aren't running, but you can't discount that the machine may be bottlen...

You could concatenate and process as a single large file, or use job parameters to pass the appropriate filename to the job in a loop.

This works well in DS, because if you compute each column separately as a separate job, staging to a hashed file for each column, then you just need to stream your driving keys and reference lookup each column. Since each column would be an equi-join, you need to zero/default fill the target column ...

Attach, check status, reset if necessary and detach and attach again, set all parameters, set run limits, run job, wait for finish, check status.

Best practice: Build your target row within DS and then either insert or update it once in the target. DB i/o is a performance killer.

Actually, failure to open DS_JOBOBJECTS means that the physical repository file that contains all job information is missing. The repository is corrupted. The Routines and Table Definitions are stored in a different file, if you can get an export of them for safety. Your only choice is to either do ...

That's my second post on this topic, my first answer (before yours) seems to have been ignored.

Make an export for all your projects, try upgrade in place, if that doesn't work, de-install and then install and re-import.

There is no challenge. Look at the split command, you can tell it how many lines files should contain. One single Unix command and you've got your split files.

Your only challenge is deciding how to add the control lines.

Still set the minimum modulus. You already know the file is going to be big, why start from the smallest possible size and grow from there? Find your high watermark size and go a little over that. The key pattern means if your file has a primary key value of 1 to some big number then you can get a p...

Consider writing a date validation function with range checking, or use a TIME dimension table and validate every date.

Separate your creating of header/control/footer from data transformation processing. 1. Transform and create your data in a single large file. 2. In a Sequencer w/Command stage or a Batch job with API call use the unix split command to generate n files of 994 rows. 3. Use a standard process to read ...

Spool to a file in one job, transform in another splitting inserts from updates into separate files, then a job to apply inserts and another for updates. Your fundamental problem is that you're querying the same table you are loading. You should NOT do this. You're using rollback to hold the entire ...

That's your problem. You should ALWAYS use physical drives local to the server for hashed files.