Unable to retreive data on a hash look up

NEO · Post by **NEO** » Wed Oct 13, 2004 2:45 pm

Hi,
I am seeing some strange behavior from a hash file. I write a NAME and an associated value to a Hash file. The NAME is the Key. I try to retreive the value associated with that NAME from another job using the HashFileLookupUtility. It works fine for various values of NAME where I write to the HashFile and retreive it. but theres one NAME thats giving me problems lately.The NAME already exists and the associated column is getting updated alright. I can see it When I open the HashFile in NotePad, but its unable to retreive the value. Its returning a null. All other NAME values, its giving me the right result. Do I need to fix the hash file or something?
Its strange because I never has this problem before doing exactly the same thing on the same NAME.
Thank you.

dhiraj · Post by **dhiraj** » Wed Oct 13, 2004 3:21 pm

Neo,

trim the Name field before you write in to the hash file. Also use the trim function, before looking up for the name.

HTH
Dhiraj

NEO · Post by **NEO** » Wed Oct 13, 2004 3:32 pm

dhiraj wrote:Neo,

trim the Name field before you write in to the hash file. Also use the trim function, before looking up for the name.

HTH
Dhiraj

Hi Dhiraj,
I am actually doing a TRIM while writing and reading. Actually, the UtilityHashLookup routine returns a "RECORD NOT FOUND" string if it cant find the key value. I am getting a null instead. And I can retreive all other values except this one. And the particular NAME value is a simple string like all others. All others work fine. That is what is strange!

ray.wurlod · Post by **ray.wurlod** » Wed Oct 13, 2004 4:17 pm

Using an external editor, determine whether this particular value contains any non-printing characters, such as Esc. You (as a human) won't be able to see them, but they can cause a lookup to fail.

NEO · Post by **NEO** » Thu Oct 14, 2004 7:26 am

ray.wurlod wrote:Using an external editor, determine whether this particular value contains any non-printing characters, such as Esc. You (as a human) won't be able to see them, but they can cause a lookup to fail.

As strange as it may sound I dont see anything unusual with this particular string compared to others in the file. It just wouldnt retreive a value just from that particular string. I even tried retreiving by cutting and pasting that string into my routine and it still gives a null. I would be interested to know that even if the file got corrupted, how it could have happened. I do a simple write and read from it and I dont see why a perfectly working file before, wouldn't work for a particular value now! I thought to err was human and that is the reason we have computers

I guess I'll just try deleting the file and rewriting again. The data is not historical anyway.

NEO · Post by **NEO** » Thu Oct 14, 2004 7:35 am

I ran into another problem. I just deleted the file the usual way and not the clear.file method and now my job is not running as it says
""TheFileName" is already in your VOC file as a file definition record."
How do I fix this now and what is the best way to delete a hash file through administrator. I think CLEAR.FILE still keeps the file but removes the contents. What is the best way to delete all traces of the hash file?
Thanks,

NEO · Post by **NEO** » Thu Oct 14, 2004 8:34 am

NEO wrote:I ran into another problem. I just deleted the file the usual way and not the clear.file method and now my job is not running as it says
""TheFileName" is already in your VOC file as a file definition record."
How do I fix this now and what is the best way to delete a hash file through administrator. I think CLEAR.FILE still keeps the file but removes the contents. What is the best way to delete all traces of the hash file?
Thanks,

Fixed the problem. I had to do a
DELETE FROM VOC WHERE NAME='Hash File Name' from the administrator. Now my routine creates a new hash file and is also able to retreive it for the above string that was giving me problems. I guess for some reason my old hash file at the place where my string was got corrupted. Well, one of life's uncertainities!
Thanks.