>Eric,
>
>I have never encountered the situation you describe and I use transactions alot. I would suggest first to check any write chache you might have going on on the file server. Next I would suggest insuring that the tables that the view gets data from are not open and buffered when you update the view. If they are you must also update the tables after the views.

Jim,

The tables are not buffered, they are only opened implicitly as a result of opening the views. 99% of the time things work correctly. Below is text from a previous thread here on the UT that describes the problem exactly. I appreciate your experience with FoxPro and if possible would like to determine what might be different about your implementation than my own.

Also, what to you mean about "write cache on the file server". Please explain.

Thanks.

Text from previous thread:

TO EVERYBODY THAT CAN HELP ME:

WHEN A TABLE HAS AN INCORRECT RECORD COUNT, USUALLY ONE LESS THAN THE ESTIMATED RECORD COUNT, AND YOU APPEND OR INSERT A RECORD TO THAT TABLE, THE END TRANSACTION EXECUTE A ROLLBACK ONLY IN THE DAMAGED FILE, BUT THE OTHER TABLES UPDATE O.K. GENERATING AN ERROR IN THE INTEGRITY OF THE TRANSACTION.
SUCH DAMAGES TABLES WORK O.K. IF YOU DON'T HAVE A TRANSACTION OPEN.

THIS ERROR IS PARTICULARY IMPORTANT BECAUSE I FOUND AT LEAST 80 CASES IN 15 DIFFERENTS LOCATIONS WITH CORRUPT HEADER THAT LOST RECORDS AND NO ERROR WERE GENERATED BY VFP TO PREVENT THE END OF TRANSACTION

THIS ERROR IS ALWAYS REPRODUCIBLE WITH VFP 5.0, 5.0a and 6.0 IN A CODE LIKE THIS:


USE MYTABLE && A TABLE WITH AN INCORRECT RECORD THAT BELONG TO A DBC

BEGIN TRANSACTION

APPEND BLANK

BROW && YOU SEE THE NEW RECORD

END TRANSACTION

BROW && THE NEW RECORD IS LOST !!!


DO YOU HAVE ANY WORKARROUND AVAIABLE ?

THANKS

[Troubleshooting] Re: END TRANSACTION works like ROLLBACK !!! Thread #188654 Message #189002
From
Dragan Nedeljkovic
Alas Ltd
18/02/1999 15:05:56 To
Gustavo Viceconti
Neuralsoft
17/02/1999 16:52:37
>use Mytable && A Table With An Incorrect Record That Belong To A Dbc
>begin Transaction
>append Blank
>brow && You See The New Record

Insert a
=tableupdate()
here. That's the effective part of the transaction which you didn't run, so nothing actually happened.

>end Transaction
>brow && The New Record Is Lost !!!
>
>do You Have Any Workarround Avaiable ?
New address of Other voices from Serbia antiwar campaign site

[Troubleshooting] Re: END TRANSACTION works like ROLLBACK !!! Thread #188654 Message #189900
From
Gustavo Viceconti
Neuralsoft
22/02/1999 05:17:51 To
Dragan Nedeljkovic
Alas Ltd
18/02/1999 15:05:56
>>use Mytable && A Table With An Incorrect Record That Belong To A Dbc
>>begin Transaction
>>append Blank
>>brow && You See The New Record
>
>Insert a
=tableupdate()
here. That's the effective part of the transaction which you didn't run, so nothing actually happened.
>
>>end Transaction
>>brow && The New Record Is Lost !!!
>>
>>do You Have Any Workarround Avaiable ?

I don't have buffering enabled because is very much slower, (nearly 10 times to complete a transaction).

thanks anyway

I found a workarround for this problem and I hope you could use it.
Here's the example

*** You must test every table before BEGIN TRANSACTION

PPA=ADIR(PPB,LOCFILE("mytable.DBF"))

SELECT 0
USE mytable AGAIN
PPT=HEADER()+1+RECC()*RECSIZE()

IF PPB(2)<>PPT .AND. PPB(2)<>PPT-1
do error
ENDIF

USE


procedure error

** ONE ALTERNATIVE

CLOSE DATA ALL
USE MYTABLE EXCL
APPEND BLANK
DELETE
PACK


*** ANOTHER ALTERNATIVE IF YOU HAVE FOXFIX

CLOSE DATA ALL
=FIXDBF("MYTABLE.DBF",1)