What I've done for these situations is to create a transaction class to encapsulate this behavior. It contains an AddCursor method that maintains an array of view aliases that participate in the transaction. The Save method loops through attempting TableUpdate's and either commits (END TRANSACTION) or issues ROLLBACK and optional TABLEREVERT's. The Save method returns .T. or .F. depending on success.

This gets you out of the "loop" of writing transaction-specific code and is more maintainable, I have found. It can be particularly helpful when some of the views are "optional" in a transaction. For example, if records in a child relation were not applicable in a particular application context, the app simply does not add that cursor to the transaction. This is easier than trying to insert option controlling code in hand-coded transactions.

-- Randy

>Wrapping up my first all view based app and I wonder if this method of handling the updates looks reasonable. No error trapping or resolution yet - just getting basics down. Thanks.
>
>

>BEGIN TRANSACTION
>SELECT vporders
>llret = TABLEUPDATE(.T.,.F.)
>IF llret
>  SELECT vpordets
>  llret = TABLEUPDATE(.T.,.F.)
>  IF llret
>    SELECT styles
>    llret = TABLEUPDATE(.T.,.F.)
>    IF llret
>      END TRANSACTION
>    ELSE
>      ROLLBACK
>      * option to bail the entire session
>      *!*  =TABLEREVERT(.T.,"vpordets")
>      *!*  =TABLEREVERT(.T.,"vporders")
>      *!*  =TABLEREVERT(.T.,"styles")
>    ENDIF
>  ENDIF
>ELSE
>  THISFORM.goodsave = .F.
>ENDIF
>

>
>Whadaya think?