I have been reading on the forum (2003 posts), that it is not advisable to use SEQKEY when you have multiple users adding and updating the same data file due to the possibility of more than one person getting the same key and the last save overwriting the previous. Is this still a problem? Is the %SK% field not incremented until after the new record is saved, or has that been fixed so that it is incremented immediately?

If it is best to work around it, is there code posted anywhere to do this?

Don Pederson

Don,

I use this function. It will leave "holes" if the user gets a key and

does not save the new record, but I never worry about that.

Compile Function ARCS_GetSeqKey(filename)

Open "DICT.":filename to hdfile then

Read rec from hdfile,"%SK%" Then

	thiskey=rec

	nextkey=thiskey + 1

End Else

	nextkey=1		

End

Write nextkey on hdfile,"%SK%" then

End	

Return nextkey

End

REturn 0

[email protected]

ARCS, Inc. [img]http://www.arcscustomsoftware.com/images/dolphin.gif[/img] </QUOTE> ---- === At 08 AUG 2005 11:33AM [email protected]'s Don Bakke wrote: === <QUOTE>Don, Although this is a well documented problem with [i]AREV[/i], I do not believe this is a problem with [i]OpenInsight[/i]. We have used SEQKEY for years without any inherent problems...at least not the ones that you are describing. Even the AREV problem was fixable if you setup your Shell correctly (Aaron from Sprezz has a post somewhere on this.) Now, this doesn't mean SEQKEY is perfect. For instance, it will not plug holes automatically. Another problem we discovered is when an end user saves a record and continues to enter a new record very quickly. Due to embedded Yield() statements in the system event handler, it is possible to lose focus on the Key ID field before the default value is populated. Thus, data is being entered without a Key ID. When the end user attempts to save the record they get an empty key error message. Then when they input a key, they get a savewarn message since it is [i]now[/i] trying to read the record associated with that key. Not nice... Many here have advocated a custom solution that avoids this problem [b]and[/b] avoids gaps in the sequence. A typical approach is to not display a sequential key at all but always display something like "". The real key is assigned during the LOSTFOCUS event of the Key ID control or during the WRITE event. Unfortunately this will take more work to implement. [email protected] [url=http://www.srpcs.com]SRP Computer Solutions, Inc.

Paxton,

Shouldn't you include a "locking loop" before reading the %SK% record? Otherwise, you could potentially run into a duplicate key issue if two users tried to set up a new record at the same instant.

I acknowledge that the possibility is remote, but I always used a lock when I had a routine almost identical to that.

[email protected]

Greyhound Lines, Inc.

Re this and responses to date.

As far as I am aware the standard SEQKEY (usually!) works fine on networks including locking of %SK% (which seems prudent if not essential).

However, we had a problem a year or two ago with 4+ users hammering new records into the same file at high speed on a slightly slow network. Just occasionally the odd new record simply didn't get filed.

Couldn't find cause or fix so wrote simple replacement procedure which has been fine ever since. Default key is "New Entry" and a pre-save script detects this, finds next key and does the necessary.

Hope this helps.

View this thread on the forum...