>>As you can see I have the adndeleted set above, but when I run the query one time the query tells me adndeleted = .T., I then close my tables and open the view, requery() giving the same parameter and I get adndeleted = .F. I have not changed anything in the local table, I am just requering the view after opening and closing it. I get the one record everytime I run the query, so I know the data the view is giving me is correct, but the adndeleted flag is coming back wrong on several of my requeries. Any ideas..
>
>
>I think from reading the other tables, it seems that deleted() is not reliable with multi-table queries.
>
>Ok... IS THIS A BUG...
>
>Everyone in the thread:
>
>It seems to me, that if you use a view with set deleted off, the records in the table that are deleted should ALSO be deleted in the VIEW... After all, isn't that the point of having a view?
>
>Actaully, I think the view should work as a table. Reguardless of the set deleted setting the view should contain the deleted records... any operations done against the view would respect SET DELETED...
>
>So, if I changed set deleted it would change the visibility of the deleted records in the view to all the various commands.
>
>After all, the DOCS say that you can treat a view the same as a table.
>
>BOb

Once they're created, Cursors and Views act pretty much the same as tables. (Except for Cursors created by SQL SELECT not being updatable, and Cursors not being PACKable. Maybe there are other exceptions, I'm sure others will jump in if they think of some.)

I think what you're finding fault with is the way they are created. Remember that they're copies of another table. Does that help?

Did you ever use APPEND FROM in 2.x (or VFP for that matter)? Remember how it appends DELETED records, without marking them as DELETED? Did that make you say there was a bug in the table APPEND FROM created, or in the APPEND FROM command? ;) ;)

Cheers,
Rich.