Nancy,

I've never had tableupdate() return .f. in a normal data update/add mode. The only time I ever really worry about it's return is in the case of record Delete where the RI rules come back preventing the deletion and I inform the user that child records prevent the removal of this item and tablerevert(), but that kind of delete code only runs against row buffered parent tables not child p-views.

>3. I knew there was a problem because TABLEUPDATE( 0, .T., 'lvw_wlevel') returned .F. on just a few records. And only when I was creating more than 30 or so.

I always use 1 as the first parameter.

>4. I added some code and now the code is well-behaved. But it could be accidental. What I've done is SCATTER NAME aErrors[] any record that fails the tableupdate and revert the record. Then, when I'm done with the scan loop in which I add the records, I check the array. If it has any "bad" record objects, I APPEND BLANK into the view, and GATHER FROM the object. And this works. But I distrust it < shrug >.

*shiver* that's the kind of code that always comes back to bite me, I usually try to figure out the real root problem. Do you have table/field/RI rules that are causing tableupdate() to choke on some records? What's different about the rejected records vs accepted records?