Clever function, Patrick, really streamlines the question. Of course the first character of GetFldState(-1) refers to the Deletion byte but I suppose it should go the same route as the rest of the fields...

One thing - since you're not specifying an Alias() any chance it is not the one currently Select-ed?

I tried this with a table in DE, set to BufferModeOverride=0 and it failed with a 'Row/Table Buffering required'. I changed it back to 3 and it worked. I didn't try setting it through code.

HTH,

-Irv.


>Hello All,
>
>I'm hoping someone can clarify a point that's bothering me for some time. I have code in the stored procedures of my databases that looks like this:
>
>llAdding = INLIST(LEFT(GetFldState(-1), 1), "3", "4")
>
>llAdding will be set to .T. if I'm in the process of adding a record and will be .F. if I'm editing a record.
>
>All of my data entry forms use parameterized views (which of course are row buffered by default). So everything works just fine.
>
>However, if I use a table from the command window (no buffering) and insert a record, the above code still works just fine even though the table is not buffered. According to the documentation, GetFldState() only works on buffered data. I was really suprised that the above code is still working. I was concerned that if a user happens to have VFP installed and somehow opens a table and modifies or add data, the above code would not be able to tell if the user is adding or editing an existing record.
>
>So I have tested the code in the stored procedures when using a table directly (no buffering) and just before and after the variable is set, there is indeed no buffering (CursorGetProp("Buffering") = 1), but the variable is set to .T. if I am adding and set to .F. if I'm editing.
>
>So I'm wondering if anyone else noticed this behavior? By the way I'm using VFP6 with service pack 5.
>
>Thank you very much
>Pat Moran