DSXchange

Logs are hashed files within the project directory. You really need to consider stopping this train of thought because the log information is not stored in a manner that is relational. The log for a job is dependent on its job number, which changes whenever you copy or import a job. Please accept th...

Your dsenv file contains paths to the Oracle home and shared libraries. You need to install the 32BIT Oracle client and update the dsenv file. Recycle the DS services and you should be fine.

If used in before/after job routine, you can set under the job properties that non-zero return codes are treated as fatal errors. Have your shell script return the appropriate value.

Suggestion #1, turn your job around and use the reference as the driver table. Rather than using a 1 to many processing design, use a many to 1 processing. If your reference table sets the maximum number of rows you are allowed, then it should be the driver. You won't be doing a multi-row lookup any...

The problem is a common one. The issue is that your command is being stripped of the double quotes. The DSExecute API has issues when you try to do what you're doing. The recommendation is to use a shell script that does all of the steps that you need, with the variable information passed as argumen...

Your log is corrupted, maybe because of it exceeded 2.2 GB. You can try to recover the contents, but the easiest thing to do is clear it out completely. From DS Admin, connect to that project and issue "CLEAR.FILE RT_LOG1056". You'll lose the purge settings for the job, but at least the log (and job...

Only put into the hashed file the rows necessary for processing on a given run. If your hashed file is coming from small table, just copy the table to the hashed file. But, if the table is huge, use meaningful information (probably from the source data being processing) to inner-join reduce the amou...

Look at the "rmdir /S /Q \fullyqualifiedhashedfile" command to remove a hashed file directory and its contents, then "erase \basehashedfiledirectory\D_hashedfilename" to get rid of the D_hashedfilename file.

My constraint has columns from primary as well as from the reference If you can put an condition in the constraint that uses columns from the primary and reference links, then pass the primary link values as "keys" to the reference lookup and use the cursor variable number in the query as part of t...

I'm sorry, I'm not tracking where this post originated. Is your original problem about saving a job? These error messages are explanatory, the first warns that the second could occur (and it did), what more do you need supplied?

Your query must be malformed if it's not returning 24 rows per lookup. Why isn't your constraint part of the WHERE clause?

Someone somewhere has a Director Monitor open on that job. Start by exiting all Director sessions on your PC and try again. If that doesn't work, starting asking everyone to get out and try again. If every single person is out, then recycle the DS services as something is obviously wrong internally ...

You're positive you didn't reuse the same file name on multiple links? Otherwise, verify the path was valid, as it could have a file created with the directory as part of the name because of a non-existent directory. On a side note, you should have multiple output links from the ODBC stage, so that ...

Research the forum for T30FILES and MFILES discussions, your problem is that the system was intantaneously out of ability to open/work with more dynamic hashed files.