DSXchange

Hi,

Is it possible that the total number of rows inside a Hashed file NOT equal to the total number of rows mentioned in the input link to the same Hashed file?

If so when and also how to get total number of rows inside a Hashed File.

Thank You,
Arijit.

That is definately possible, you could write 4 million records into the hashed file, and if all the key values were the same the job would report 4 million records on that link (which is correct) but the hashed file would be left with one one record as it overwrites based on the hashed file key.

If the hashed file has been created under the account, or if a pointer has been created for it you can run SQL against it to get the count of records in the hashed file.

Yes, it's possible that the total number of rows inside a Hashed file NOT equal to the total number of rows mentioned in the input link to the same Hashed file.
Check log file to know actual total no. of rows loaded into a Hash File.

Any job log will only show how many records were written to a hashed file, not what it ended up containing.

As noted, a hashed file with a VOC pointer can be counted with normal sql or with EXECUTE COUNT RETURNING. Or build a brain dead job that sources from the hashed file to a sequential file but with an @FALSE constraint in the Transformer stage between the two. The number of records read can then be observed when the job runs.

Or go inside your Administrator and simply type the command If the hashed file is a pathed hashed file, then create a VOC entry using SETFILE command and use that VOC name as the hashed file name.

DSguru2B wrote:Or go inside your Administrator and simply type the command

Code: Select all

COUNT hashedfilename

If the hashed file is a pathed hashed file, then create a VOC entry using SETFILE command and use that VOC name as the hashed file name.

Thank you very much. I had a problem in which I had to get the changed rows using CRC logic. I tried to load the all data(CRC coded) into the hashed file during first run and lookup the same hashed file in the second run. But the hashed file seems to miss some rows even if there are no duplicate rows at source.

Check if both your source and hashed file have the same set of keys.