DSXchange

Make sure all columns have proper derivations. In other words, you dont see any red in the transformer. Do as rohit suggests, hit more and see why the compiler is complaining.

I suspect the same. The hashed file is being created at one place and being accessed from some other location. Please make sure both creation and usage of the hashed file is from the same location.

In such a case use the database's ability to generate keys. Like in SQL Server, you make the key column as an identity column. This way the database generates a key everytime a record is inserted. One of the best ways to go about if multiple applications insert in the same table. If your concern is ...

This site is full of patterns and best practices. You can even check out Vincent's blogs. Kims has some tips on his home page. Search is the key. And if you have time, you can even prepare a white paper or build sample templates and share it with us

Actually its safe to leave both 'create file' and 'delete file before create' options checked in job1 if thats the job that always runs first and creates a fresh hashed file. Its just job2 where you need to uncheck both these options and use the name of the same hashed file as job1.

Use the power of unix. Sort it by the first column, get unique values of the first column using unix uniq command to build the files. Then use the grep to get all the values for a particular employee. Something like sort myfile.txt | uniq | awk '{print $1} > filenames.txt cat filenames | w...

Hats off to Kim. Great work and great support for all of us. Keep those pearls of knowledge coming

Less than 14 cents a day you can become a premium member and all shall be revealed.

You can use a custom script to extract the job logs by using the dsjob -logsum command and bring it in a readable format so that a DataStage job can pick it up and load it into a table. Or you can also use the repository tables. If you opt for the latter, just be aware the the repository structure m...

Ray is right. Its better to plan and rethink the design before implementing it. "Failing to plan is planning to fail". Especially if you are tweaking someone else's jobs. Make sure you have good amount of comments to avoid any confusion by future developers.

The Liscense for the C++ complier has expired.

You can also use the after stage subroutine to rename your file. This way you can use the oconv function to get your date in the desired format. Something like FileName = Arg1 CurrDate = Oconv(Date(), "DMDY[2,2,4]": @VM : "MCN") NewFileName = FileName:"_"...

As long as the job is opened in the designer, you will see it in the lock section in the director. "Cannot get exclusive access to the executable file for job XXX. Job may be being monitored" is also thrown by the designer when the job was being monitored and the monitor window was not closed. Also ...

I would also suggest use of Rnd function. Instead of the uv stage as Ray suggested, you can possibly have a temp table which can only have access by your etl id for security purposes. That will help speed up the process. If the number of records is low (<1000). Even the uv stage will suffice.

What else is the job doing? Open the designer and try to view data , see how much time does it take to retrieve data. If its not taking that much time then the other transformations must be taking time. Do you have any after job subroutines? If you do then once the job executes, the status still rem...