I guess I'm confused about exactly when you call the GetFldState function. All I did was Select the table in code and then issue your command. It returned an error unless the Table was buffered...

You may be right about record validation causing automatic buffering; do you actually call this function in the Record Validation rule from Table designer? I will try to see if it will work in this case...

I'll check messages later, travelling to another site now...

-Irv.


>Thanks for the reply Irv,
>
>The first character in the string returned from GetFldState() is indeed the deletion status. If this value is "3" or "4" I am indeed working with an appended record. The correct alias is the current work area so I did not use the optional cAlias for the GetFldState command.
>
>I am not seeing the message that you see. If I open the table and do not buffer the data, I can still use the GetFldState() function in my record validation rule. Even with the data not buffered, it seems to work correctly. Does VFP somehow (internally) turn on buffering when you call a record validation rule? It must because I don't get an error when the data is not buffered and I call GetFldState(). It correctly returns "3" or "4" in the first byte if the record was appended to the table.
>
>thanks
>Pat
>
>>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