Hi Mike, I have seen this coding style sometimes. Yes, you can change the APPEND BLANK / REPLACE combos with an INSERT INTO without any negative siedeeffects.
The part with that GO BOTTOM / SEEK() was normally done for repositioning other tables, which are linked with a SET RELATION. You could substitute four lines (together with that "lnNotes" stuff) with a simple GO RECNO(), which does a reposition to the current recno together with a buffer refresh. Interestingly in the SEEK, they use a TAGname "notes_id", but later on do a SET ORDER TO "id" , not "notes_id". Was this a failure on your "copy code" job, or do they really have two tags? For your third question: Index files are only updated, if indexed fields (or expressions) are touched (means: they get updated in any way). Writing to non-indexed fields does not trigger index files updates. wOOdy -----Ursprüngliche Nachricht----- Von: ProFox <[email protected]> Im Auftrag von MB Software Solutions, LLC Gesendet: Mittwoch, 2. Oktober 2019 19:42 An: [email protected] Betreff: APPEND BLANK with immediate field values set right after In trying to find the "demons" in this legacy VFP app (shared/used by both desktop and internet/website users), I find there's a lot of APPEND BLANKS everywhere followed by an immediate REPLACE (and sometimes more than 1). Here's a sample of my findings: SELECT notes APPEND BLANK REPLACE notes.id WITH order.invoice REPLACE notes.dtg WITH DATETIME() LOCAL lnnotes_id lnnotes_id = notes.notes_id = TABLEUPDATE(.T.) GOTO BOTTOM = SEEK(lnnotes_id, 'notes', 'notes_id') SET ORDER TO ID thisform.pgf1.page5.grdnotes.coldetail.setfocus() Now, 1st, I'd say "switch this over to explicit INSERT INTO MyTable (ID, Dtg) VALUES (order.invoice,datetime())" Also, not sure why they're go to the bottom and then reposition the record pointer immediately afterwards. That's wasted moves/cycles, imo, although perhaps minuscule. If the user did NOT have table buffering in place, I can see a bigger knock against this approach because with every update, the table's CDX indexes would all have to be updated (if those fields were involved). The backend table's CDX file isn't updated on changes to the buffered cursor. Question: if you update fields that are indexed, I know the index file has to update to reflect those changes. If you update fields that are NOT IN ANY INDEXES, there's no update needed for the CDX then...right? Any other tips? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
