Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Multi-user Updating Problem
Message
From
19/06/1998 22:03:50
Shihchau Tai
Apic Systems Pte Ltd
Singapore, Singapore
 
 
To
19/06/1998 14:36:00
Larry Long
ProgRes (Programming Resources)
Georgia, United States
General information
Forum:
Visual FoxPro
Category:
Client/server
Miscellaneous
Thread ID:
00109357
Message ID:
00110131
Views:
30
One last question.

When the tables are on buffering mode, I always put statements like 'Replace', 'Insert' before Begin Transaction. Is it correct?

Just want to confirm.

Thanks for the answer. I have had some refresh problems on the Novell server and I wonder if LOCK and UNLOCK can solve my problem.


>Perhaps something like this...
>
>IF !tableupdate(1,.f.,table1)
> rollback
>ELSE
> if !tableupdate(1,.f.,table2)
> rollback
> else
> end transaction
> =RLOCK(TABLE1)
> UNLOCK IN (TABLE1)
> =RLOCK(TABLE2)
> UNLOCK IN (TABLE2)
>ENDIF
>
>>Where do I put the RLOCK and UNLOCK in this case?
>>
>>I usually do:
>>
>>[Update Tables]
>>
>>Begin Transaction
>>IF !tableupdate(1,.f.,table1)
>> rollback
>>ELSE
>> if !tableupdate(1,.f.,table2)
>> rollback
>> else
>> end transaction
>>ENDIF
>>
>>Isn't this the usual approach?
>>
>>
>>>>The solution given by Fred Lauckner on 20/05/98 is very helpful, it's solved my problem and I would like to thank him.
>>>>
>>>>Now, I have another problem, when two users same the data to the table at the same time, sometime one of it table is not updated.
>>>>Is there any different of the below two coding? Because when I used sample (1) to update my data which is enter in grid, the data is gone if the program perform (=tablerevert(.t.)) function.
>>>>
>>>>(1)=====================
>>>>Begin Trans
>>>> (update table)
>>>> =tableupdate(.t.)
>>>>End Trans
>>>>
>>>>(2)=====================
>>>>Begin Trans
>>>> (Update table)
>>>>Endd Trans
>>>>=tableupdate(.t.)
>>>>*=======================
>>>>
>>>>Thank in advance.
>>>>
>>>>From
>>>>Ms Thian
>>>After many days of trouble shooting, I found that the only way to guarantee that the data on the server is current is to issue
>>>
>>>rlock()
>>>unlock
>>>
>>>Immediately after any table updates. For example...
>>>=TABLEUPDATE()
>>>RLOCK()
>>>UNLOCK
>>>
>>>I am pretty sure that the problem comes from buffering at the server. Issuing the rlock(), apparently forces a write and read of the actual data.
>>>
>>>Let me know if this helps.
>>>//:^)
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform