Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
SCAN Confused?
Message
From
06/06/2001 10:56:44
Jason Mesches
Ocean Systems Engineering Corporation
Carlsbad, California, United States
 
 
To
06/06/2001 09:49:08
Carol Dewar
Magram Computer Services Llc
Saugerties, New York, United States
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Title:
Miscellaneous
Thread ID:
00515720
Message ID:
00515791
Views:
17
>My officemate needed to add a primary key to an @10,000 record database.
>He added PKEY a DateTime field.
>He figured, since users add records by an Add button, then fill in the rest; Replacing PKEY with DATETIME() on add is fine. I wonder if that is enough.
>
>Anyway, after he added the field PKEY, he wrote a small prg to update the @10,000 records:
>
>USE Mtg EXCLUSIVE
>ldCount = {^2001-01-01 12:00:00AM}
>SCAN
>   REPLACE PKey WITH ldCount
>   ldCount = ldCount+1
>ENDSCAN
>
>
>When he tried to add a primary index on PKey, he got the uniqueness violated error.
>He is running VFP 6.0 SP5 and Win 2000 SP1.
>(This is from memory.)
>I queried the database, and found 26 PKey dups. Starting around record 92000, and about every 7th or 8th record thereafter; there was a dup, then a skip.
>
>I mean: RecNo             PKey
>        92008 {^2001-01-08 09:20:08AM}
>        92009 {^2001-01-08 09:20:08AM}
>        92010 {^2001-01-08 09:20:10AM}
>
>I fixed this by changing his prg to: REPLACE ALL PKey WITH ldCount+RECNO()
>But, I am wondering if anyone has encountered, or can explain this dupping.
>It is like the REPLACE and the var update got confused.
>
>Thanks in advance,
>Carol Dewar
>Magram Computer Services

We've run into similar issues... I've even seen it where simply scanning a "large" file (>10,000 records) and within it, issuing a single replace statement completely locks up the PC to the point of needing a reboot. The last time it happened, one of my co-workers suggested that the network (Novell) was the culprit, as it only allows x # of record locks (sorry, I forget the exact name of the setting). We tried augmenting x and found that more updates were occurring before the next crash, but, inevitably, the next crash would come. We finally got around it by doing this:
SCAN
   REPLACE somefield WITH somevalue

   IF MOD(RECNO(), 10000) = 0  &&change the 2nd parameter as you see fit
     FLUSH  &&forces updates to the disk, avoiding the scan locking more records than the network can handle
   ENDIF
ENDSCAN
I think everyone else already addressed PK issues, so I won't be overly redundant. Hope that helps.
---J
Previous
Reply
Map
View

Click here to load this message in the networking platform