I would like to know the OI method for users to change the sequential keys. In AREV the user could enter an equals sign followed by thge new value. Any clues gratefully received.

The SEQKEY is held in your dictionary table in the row %SK%. This can be modified but not in the same fashion as in ARev. This article should help you on your way.

- Stephen Revelation

Tony,

The functions in the article Stephen refers to might be too simple for a multi-user app. I had an unfortunate case once where two users got the same key and overwrote each others rows…

Here's a function that gets a key and locks too: http://www.revelation.com/WEBSITE/DISCUSS.NSF/f12696d31000b22a8525652b00831bb2/26b5e3cd1bb74613852563a9006b8b79?OpenDocument. That makes sure two users don't get the same key. (I won't take the time to check the code again, but I'm certain that means you must remember to unlock when you write back.)

I never used that function in its original form but modified it (cannibalized useful bits) so that it updates and writes back the counter, and releases the lock. What it does is to get an available a key, and make sure nobody else can get the same key. You see in my app I had a process where there was a significant delay between when I got the new key and when I finally used it. So I couldn't keep %SK% locked. (But since in my app the user can abort that process before the key is used, the database can end up with "holes" in the key sequence.)

Here's my modified function:

function Reserver_SeqKey2( TableVar, DictVar )

/*

("Reserver_SeqKey2"=make a reservation for a new seq key - Mk 2")

improved version of earlier function Reserver_SeqKey. locks.

taken bits from Mmartin@Revelation.Com (Mark Martin)'s function GetSeqKey.

the function finds and returns the next available seq key, and immediately increments %SK%.

since it locks %SK%, other users cannot grab the key from under our noses.

the %SK% record is numeric ONLY.

upon an error condition, an Alpha value will be returned.

potential failure values (and why) are:

"NOWAY" - default setting - should NEVER be returned.

"PARAM" - no TableVar or DictVar parameter passed in.

"LOCK" - max attempts to lock failed - 500 tries!!!

"READ" - couldn't read %SK% from dict.

"WRITE" - couldn't write back %SK%.

"UNLOCK" - couldn't unlock %SK% after write.

• /

$insert Logical

equ MAXLOCKTRIES to 500

declare subroutine Delay

declare function Assigned

KeyVal=NOWAY"

if not(Assigned(TableVar)) then

	KeyVal=PARAM"

	goto Exit

end

if not(Assigned(DictVar)) then

	KeyVal=PARAM"

	goto Exit

end

/* lock the value to ensure that we coordinate properly with the system */

Locked=false$

CannotLock=false$

LockTries=0

loop

until Locked or CannotLock

	lock DictVar, "%SK%" then

		Locked=true$

		LockTries=0

	end else

		LockTries += 1

		/* wait 1/2 second and try again... */

		Delay( .5 )

	end

	if LockTries ]= MAXLOCKTRIES then

		CannotLock=true$

	end

repeat

if CannotLock then

	KeyVal=LOCK"

	goto Exit

end

read Rec from DictVar, "%SK%" else

	KeyVal=READ"

	goto Exit

end

SK=Rec

Free=false$

NewSK=SK

loop while not(Free) do

	readv Dummy from TableVar, NewSK, 1 then

		NewSK += 1

	end else

		Free=true$

	end

repeat

writev NewSK on DictVar, '%SK%', 1 else

	KeyVal=WRITE"

	goto Exit

end

KeyVal=NewSK

unlock DictVar, "%SK%" else

	KeyVal=UNLOCK"

	goto Exit

end

Exit:

unlock DictVar, "%SK%" else null

return KeyVal

- Oystein -

I'm glad you pointed out that the article is not suitable for multi-user apps. It really should be updated.

Can we assume that the problems with %SK% within AREV forms does not exist in OpenInsight? I know now that AREV's problems can be corrected by the way you start your main menu, but I've never heard whether OpenInsight can accidentally release the lock on %SK% under any obscure circumstances as well.

dbakke@srpcs.com

SRP Computer Solutions

View this thread on the Works forum...