>Hi all,
>
>I have had this problem before and it seemed to be solved but now some users have surfaced it again.
>
>Users have a form and it shows in a list all the "quotes" that have been done for a client. They can edit a quote by double-clicking it and the editing is done in another form with its own data session.
>
>They also have the option of highlighting a quote(s) and "copying" it so that they can update the pricing without editing the previous version. And then basically a "copy" is to copy the original records, assign them new primary keys and insert the new records into the table.
>
>Here is my code somewhat abbreviated. I have tried various methods of inserting records but below is the current. Note that there is a header record for each quote and then multiple child records (pricing detail lines).
>
>

>
>* get the header records
>SELECT * ;
>   FROM Quotes ;
>   WHERE Quotes.Quote_ID IN ( SELECT Quote_ID FROM QuotesToCopy) ;
>   INTO CURSOR TempHeaders READWRITE
>
>SELECT * ;
>   FROM QuoteDetails ;
>   WHERE QuoteDetails.Quote_ID IN ( SELECT Quote_ID FROM QuotesToCopy ) ;
>   INTO CURSOR TempDetails READWRITE
>
>* scan these replacing the primary keys and foreign keys in each cursor
>SELECT TempHeaders
>
>SCAN
>
>   * not shown: basically, cursors are writable so update keys in cursors before moving into tables
>
>ENDSCAN
>
>* move the data into some views for posting; note that I have also tried in the past to insert directly into the tables but this is latest iteration thinking that when I switch to remote views, this would be better
>
>* open local views and set buffering
>USE v_QuoteHeaders IN 0
>CURSORSETPROP("Buffering",5,"v_QuoteHeaders")
>
>USE v_QuoteDetails IN 0
>CURSORSETPROP("Buffering",5,"v_QuoteDetails")
>
>* insert via SCATTER/INSERT
>
>* header records
>SELECT TempHeaders
>
>SCAN
>
>   SCATTER MEMVAR MEMO
>   INSERT INTO v_QuoteHeaders FROM MEMVAR
>
>ENDSCAN
>
>* insert details records in view v_QoteDetails (not shown, same as above: SCAN, then SCATTER/INSERT into view)
>
>* post the updates
>
>llUpdatedOkay = TABLEUPDATE(1,.T.,"v_QuoteHeaders")
>
>* do same for detail records
>
>* Now, base tables (local, free tables) are NOT buffered so the only thing left to do is to FLUSH out the changes to the OS and disk
>
>* Note: it seemed the FLUSH...FORCE was what helped the most when this was first implemented a couple years ago.
>
>FLUSH IN Quotes FORCE
>FLUSH IN QuoteDetails FORCE
>
>* for good measure, close the, cursors, views AND the tables
>USE IN TempHeaders
>USE IN v_Quotes
>USE IN Quotes
>* etc, same for detail ones
>
>

>
>So what am I missing? I know that the TABLEUPDATE on the view posts to the table; but then the table does not have buffering so the rows should just be added right away;
>and then the FLUSH...FORCE is supposed to flush it out to disk AND signal the OS to also do the same.
>
>Symptoms:
>
>1) sometimes (i.e. not always), the users cannot see the detail rows when they go into the editing screen (they can see the header info)
>2) sometimes, it seems one of the controls on the editing screen is not binding (or something) to the underlying data (which is a local view) such that when the user does a "calculation", the results are wrong (e.g. think of running a quote for 10 years of payments annually vs. monthly - there is a combolist where they set this and it does not seem to be bound to the data properly such that it fails on the calculation after the form loads).
>
>Sometimes I think it is because I do not understand what is happening with TABLEUPDATES - but I think I do. Sometimes I wonder if there is a difference when appending rows to a table via different methods (does it matter if the rows are appended via a TABLEUPDATE on a view? would it be better to add them directly via appending a blank record onto the table and gathering the data in? would it be better to use INSERT directly onto the table? - I don't know why there would be a difference because in my mind they should all perform the same action in the background...but maybe there is a bug in one method vs. the other).
>
>Any thoughts appreciated. Sorry this is so long but hopefully the detail helps.

A bit of a SWAG, but if a view may contain more than 100 rows you might have to adjust FetchSize i.e.

=DBSETPROP( "MyView", "VIEW", "FetchSize", -1 ) && -1 means to fetch all rows rather than the default maximum 100