Subject Re: Two Forms - Passing data From Mervyn Bick <invalid@invalid.invalid> Date Thu, 23 Oct 2014 16:57:32 +0200 Newsgroups dbase.getting-started Attachment(s) Unnamed File 1, Unnamed File 2, Unnamed File 3, Unnamed File 4, mbtest_edit.wfm,  Unnamed File 6, Unnamed File 7, mbtest_edit1.wfm, Unnamed File 9, Unnamed File 10,  Unnamed File 11 On Wed, 22 Oct 2014 16:15:18 +0200, edward racht <e.racht@gmail.com> wrote: > I have a challenge with my request. > > The value passes from the data HSFORM entryfield to the lookup HSCFORM   > entryfield.value > > The passed HSCForm entryfield.value replaces the first row value in the   > table.  It just is written in to the row.  I can't figure out how to   > enforce  autoedit = false. Heinz has explained what is happening. One way round this is to use non-datalinked entryfields on your edit form. You can, of course, use datalinked entryfields if you do a beginAppend() if the applyLocate() fails.  On the other hand, if you ever move your data to a SQL server you are going to have to use non-datalinked fields for editing.  Using them now will take some (not all <g>) of the pain out of the conversion process when the time arrives. ALL my tables for my own programs have, as the first field, an autoinc value.  It is not really necessary for .dbf tables but it becomes essential if one moves the data to a SQL server. On my edit form I ensure that my entryfield numbers match the field numbers ie entryfield1 is for oRow.fields[1].value, entryfield2 is for oRow.fields[2].value and so on.  This allows me to use a loop in the program to move values in and out of the entryfields.  Doing one or two by hand is not a problem but when one has, say, 20 fields it becomes a PITA. Access to the entryfield for the ID field is blocked by setting it's when event to return false. Mervyn.