You are right, but by having PK's generated locally, you can work disconnected, using offline views, and then update data on server. We have to enter large suppliers invoices, hundred(s) of detail lines or more. It's easy to take detail view offline, add records locally and then bring it online and update. And we can have master/child tables update in a single transaction. VFP and (I think) database servers have ability to compress indexes, it is not a big problem.

About your repro code, I've tried with Firebird SQL server, a remote view and 4 instances of Foxpro. Everything was OK. I think the code will be OK with a database server.
But if you want to use the same code on native tables, you must lock the source table
The code below works.

local x, nNext

CLEAR
CLOSE DATA
CLOSE TABLES
SET EXCLUSIVE OFF
SET DELETED ON
SET CURSOR OFF
SET REPROCESS TO AUTOMATIC 
lNativeTables = .t.
if NOT FILE("ShowBug.Dbc")

   CREATE Database SHOWBUG
   CREATE TABLE Test (MyID I, NextID I)	
   APPEND BLANK	
   REPLACE MyID WITH 1, NextID WITH 1
   USE

CREATE SQL VIEW VTest AS SELECT * FROM Test WHERE MyID=1
	DBSetProp( "VTest.MyID"   , "Field", "KeyField"   , .T. )
	DBSetProp( "VTest.MyID"   , "Field", "Updatable"  , .F. )
	DBSetProp( "VTest.NextID" , "Field", "Updatable"  , .T. )
	DBSetProp( "VTest"	     , "View" , "SendUpdates", .T. )
	DBSetProp( "VTest"        , "View" , "WhereType"  , 3 )

	CLOSE DATA

endif

OPEN DATABASE ShowBug
USE VTest SHARED

@2,2 SAY "Assign:"
@3,2 SAY "Source:"
@4,2 SAY "  View:"

for x = 1 to 100
   INKEY(.1)
   nNext = SqlNextID()	
   if nNext < 0
      =MessageBox("It's Dead!")
      EXIT
   else
      @2,10 SAY nNext
   endif
next

CLOSE DATA
CLOSE TABLES
SET CURSOR ON

return

********************************************************************************************************************

Function SqlNextID( cAlias )

local oldarea, x
x = 0

REQUERY()

do while .T.
	REQUERY()
	IF lNativeTables
		LOCK('test')
	ENDIF 
	nRet = NextID
	REPLACE NextID WITH NextID + 1
	if TableUpdate( .T., .F. )
		IF lNativeTables
			UNLOCK IN test
			USE IN test
		ENDIF
		EXIT
	else
		if x > 100
			TableRevert( .T. )		
			nRet = -1
		   EXIT
		endif
		@3,10 SAY Test.NextID
		@4,10 SAY VTest.NextID		
		x = x + 1
		TableRevert( .T. )
	endif

enddo	

return (nRet)

>Dorian,
>
>By all means - jump in! I kind of like using the integer primary keys, mostly due to their compactness (4 per). It's more of a pain to look elsewhere to assign them but that logic gets "black boxed" so I don't have to think about it.
>
>The issue went beyond the primary key issue into any old free table. I was able to reproduce the same "issue" when two users changed the same description field for an inventory item. It appears to happen with ANY free table - not just the one I use to get my primary keys.
>
>I can tell that I've run into a "wall" - now I'm just bashing my head against it repeatedly to see exactly how hard it is <g>.