Hi Jim,

The buffering mode is the problem. If a second user gets a lock on the record after the first user releases the lock but before the TableUpdate() has taken place then you will get duplicates. Set Buffering to 2 (pessimistic row buffering). That should fix the problem. (I've generally avoided buffering when incrementing keys, but pessimistic row buffering should be ok)

The overwriting, etc during add operations is probably due to the duplicate keys - depending how your code is written.

Hope this fixes your problem.

Regards,

Liam





>Yes, the table is buffered, using Optimized Row buffering. We are using the menu supplied with the Wizbuttons class that is distributed with VFP and used when prototyping the screens. It works very well with our other clients.
>
>I am thinking of setting the buffering to Pessimistic Row buffering to see if this changes anything. It may take a few days to implement this; we are trying to get credit card processing to work on the web site and that has priority. I will also be upgrading to VFP 8.0 to determine if the issue is resolved.
>
>During our testing, we sat two people down and had them enter 10 records each to the same data table in a short amount of time. We experienced about a 20% error rate (records being overwritten and duplication). We also received several messages about data being changed by another user. We were doing only adds, not edits.
>
>The server is a new Dell computer with a SCSI drive. It does not give us the option to enable/disable write-back cache. Our technician tells us the feautre is not available with this hard drive and should not be an issue. Disabling it at the workstation seems to have no effect. I have located MS Knowledgebase article that explains a problem with the write-back cache option not working correctly with Win 95-98-ME, but no reference on 2000 or later. This doesn't surprise me, it seems MS wipes the error slate clean with each software release and the problem has to be resubmitted.
>
>To further aggrevate the problem, we used our tech support incidences up with VFP 6.0. When we upgraded to 7.0 and tried to report a problem, we were informed that we had used our free incidences up. We had to pay as much for the upgrade as if we had bought the product new, why weren't the incidences reset?
>
>And the incidences we reported in 6.0 were either confirmed to be known problems or attributed to the operating system and not VFP, but they counted against us anyway. So we can't report this problem to MS without giving them a bunch of cash. And when we do, they will either deny there is a problem until we prove beyond the shadow of a doubt there is, attribute to the OS (or other software or hardware) or tell me it will be fixed in the next release (like so many problems reported in 3.0 that are still not fixed).
>
>
>
>>Hi Jim,
>>
>>A long shot, but is the table buffered? And, if so, have you issued a TableUpdate() after modifications?
>>
>>Regards,
>>
>>Liam
>>
>>
>>
>>>Sorry I didn't get back to you earlier, I was on vacation most of last week.
>>>The inc_key function just takes the value passed to it, increments it and passes it back. I don't believe the problem is there. There are other areas where we use numeric keys and we implement the following code:
>>>
>>>SELECT master
>>>DO WHILE !RLOCK()
>>>ENDDO
>>>m.key = attendee + 1
>>>REPLACE attendee WITH m.key
>>>UNLOCK
>>>SELECT attendee
>>>thisform.TbxKey.value = m.key
>>>
>>>We have the same problems with this code, when more than one person is adding records to the attendee table we see duplication. We can not have two people work in the same area at the same time. One can add/edit/delete records and the person next to them will not see the changes. But the next time they go into Foxpro, they can see the changes.
>>>
>>>This appears to be an issue with the buffers on the computers. For some reason it is either not writing out to the disk when changes are made, or it is not going to the server to read in fresh information. I have tried closing the master table and opening it when I want to get a new value, but that seems to make no difference.
>>>
>>>What is really irritating is that this is a rewrite of an old FP 2.6 application. The add functionality did not change, it is how we added records 10 years ago and it worked fine. Of course, that was on a Novell network. We upgraded to VFP 7.0 and put Windows 2000 on the server.
>>>
>>>This client is small and inputs less than 50 records a day in their main data tables. I have used this same code in many other applications where the workload is much heavier and we are not having this problem. The code I use to create my applications is modular, I just plug in functions and programs that I have previously created as I need them.
>>>
>>>>Hi Jim,
>>>>
>>>>It seems to me that the problem lies in the inc_key() function. That's where the duplicate key is being produced.
>>>>
>>>>Regards,
>>>>
>>>>Liam
>>>>
>>>>
>>>>
>>>>>Is anyone aware of why the following code will not work?
>>>>>
>>>>>USE master
>>>>>DO WHILE !RLOCK()
>>>>>ENDDO
>>>>>t_val = inc_key(members)
>>>>>REPLACE members WITH t_val
>>>>>UNLOCK
>>>>>thisform.TbxID.Value = t_val
>>>>>
>>>>>I have implemented this same code one numerous applications every time I want to add a record. When I try to do it with my current client, I am geting a lot of duplicate key assignments. We have disabled write-back cache on the server and workstations, and I have been executing Flush commands, but we are still getting duplicate values.
>>>>>
>>>>>The only difference between this and other applications is that we are running on Windows 2000 instead of Novell. We do not seem to have this problem at other client sites. We are using VFP 7.0, other clients are using 6.0 or 7.0
>>>>>
>>>>>Any ideas of what is going on? Has anyone else encountered this problem?