>Hi Agnes,
>>aber das ist so häßlich.
>
>Hide it in the baseclass in a method specifically called "NoMoreErrorsCausedByUpdates" ;-)
>
>[and writing about ugliness in our not-so-beautiful language is a nice point ;-)) ]
>
>>

>>THIS.Table = "Database!Table,OtherDatabase!OtherTable"
>>

>>Infact, for now this is basically the solution I use. I search all ALIASES that are in the TABLES property (this is done anyway, I work sometimes with multitables and it is a pain without it) and do the GO RECNO(). It solves the problem, but it moves the record pointer - normaly no problem, but one never know. I'm looking for something more sophisticated. (^.^)
>
>Looking for sophistication and got ugliness - shame on me...
>
>I know that such a pattern can work - but I made a rule for me to have CA / views only from 1 table source - and create another local cursor if needed from the cursors or update pregiven empty fields. Was an article on that as the best use pattern for Ado.Net some years ago, and the arguments made sense to me, so I transferred it to my work - easier in vfp IMHO as we still have SQL to work on the cursor.
>
>Makes update logic easy at the cost of data positioning code or UpdateAfterRefillOrRefresh -
>as we always have PK's, IMHO the lesser problem.
>Of course when faced with huge amounts of data, any rule will be rethought/measured ;-)
>
>regards
>
>thomas

Thomas,

It has all it's ups and downs. The multi .TABLES operation need a lot of manual coding to run properly, The main problem is to figure out if something fails. The Tableupdate logic is not very nice here. I do the one cursor one target logic on an other problem (simply to many fields for one cursor (-.-) ) - I'm unhappy with it either.

Agnes