DSXchange

One of the other common mistake is handling the warnings in seq. Many a time we have some "acceptable" or agreed warnings, but then while building the seq we need to be sure to code the seq in a way to still carry on even if have warnings (within limit).

The way I have achieved this is, by writing the start time of each job at the start of job and then keep on checking the elapsed time from this log file and if a job is running more than expected*, an alert is raised. Also, I am currently running the jobs using UNIX scripts, but then the initial imp...

Also check for the correct VOC entries (which should be in synch with the presence of the mentioned files).

Can you please detail the job design, how you have identified the "slow running statements" from jobs!
I do agree the scenario can occur in any DW but recommendations depends on Design and Functional requirements

Can you elaborate the point "But this requirement is only for job 4 and not for any other job" !

Have you sorted both the links in same order ?

Also let us know the functional requirement!

Tunning querries depends on n number of things i.e. whether db is paritioned ? whether you are using indexing efficiently ? Whether you are extracting only required collumns? .... As far as handling derivation in transformer stage is concenred it again depends but db2 normally turns to be efficient ...

APT_STRING_PADCHAR, trim sometimes don't actually trim the collumns which are padded with funny characters (depending on the default value of the env variable). So better check the collumn data, which may not be actually same (i.e may be padded with these funny values) !!

I read you don't have acess to DS which makes things tougher! But the best way I think would be to base any DS version say 7.5 first, try and explore the pdf's its features and fundamentals. For any querries forum is always there! Exploring the enhancements may be really interesting but you won't be...

"and the sqltype as char" While doing this check for the paded character (i.e. default env variable) because you may end up padding your char fields with funny characters which may not be even printable.

The syntax of the string representation of a datetime value is incorrect. Quick solution may not be the best one is to read and write your date collumn changing their data type to char. This should supress the warning. Secondly as already pointed I belive you should extract the records in a seq fil...

Please mark the post as resolved

As highlighted "insert a single active record in the target table" , we should have only one active record which if changed should be updated or if a new record not present in db comes, should be inserted. Therefore in no scenario the count of records returned from the lookup should be mor...

Ray, I will take a note of this from there on! thanks


Adasgupta,
Can You please detail your job design