Issue with KeyMgtGetNextValue routine

[sbass1]

There is IMO a minor issue with the out of the box KeyMgtGetNextValue and KeyMgtGetNextValueConcurrent routines.

Here is an excerpt:

Code: Select all

    * Read the named record from the file.
    * This obtains the lock (waiting if necessary).
    Readu NextVal From SeqFile, Arg1 Else
         NextVal = 1
    End

    Ans = NextVal
    NextVal = NextVal + 1

    * Increment the sequence value, and write back to file.	
    * This releases the lock.
    Write NextVal On SeqFile, Arg1 Else Ans = -1

We have a situation where we are using KeyMgtGetNextValueConcurrent to generate a new SK, write that to a table, then later we want to use

Code: Select all

UtilityHashLookup("SDKSequences", %Key%, "") 

to retrieve that value for insertion as a foreign key in other tables. We do this for performance reasons rather than looking up directly against the database.

The problem is, the Ans returned from the routine does not equal the value stored in the hashed file.

This issue could be fixed with this code (untested):

Code: Select all

    * Read the named record from the file.
    * This obtains the lock (waiting if necessary).
    Readu NextVal From SeqFile, Arg1 Else
         NextVal = 0
    End

    NextVal = NextVal + 1
    Ans = NextVal

    * Increment the sequence value, and write back to file.	
    * This releases the lock.
    Write NextVal On SeqFile, Arg1 Else Ans = -1

I guess I can either 1) write my own version of these routines, or 2) call

Code: Select all

UtilityHashLookup("SDKSequences", %Key%, "")-1

in our code.

Anyway, I thought I'd point this out so you don't waste the time I did wondering why your FK's were out of sync with your SK's.

[ray.wurlod]

Because, just like a sequence in - say - Oracle, what's stored in the sequence is the next available key value. Not the one you've just generated.

[chulett]

Right, the "current value" we talked about in the other threads is the next value that will be used. Not the last one used. Sorry, didn't realize there was a confusion there or that that was why you wanted to fetch it.

[sbass1]

Because, just like a sequence in - say - Oracle, what's stored in the sequence is the next available key value. Not the one you've just generated.

Ok, my bad about what the next key in the hashed file should contain. I've changed my transform to:

UtilityHashLookup("SDKSequences", %Key%, "") - 1

which does what I want. The downstream FK's are in sync with the SK just loaded into the table.