>>>>>>Hi,
>>>>>>
>>>>>>Does your application have a feature where a user can update multiple records at once?
>>>>>>If yes, do you then present the data in a grid? Or another approach?
>>>>>>
>>>>>>TIA
>>>>>
>>>>>User marks many records in a grid, set up the fields to change and enter data in not-grid PEMs. This will write record by record and let those with a problem marked.
>>>>>Normal entry is by record.
>>>>>Conflict solution of many records is hell.
>>>>>It might work for a set of complete new records - but then user is used to think record by record.
>>>>>
>>>>>The single one place where I do this is the settings form of Bin2Text - but then this is for a single developer on the VFP IDE.
>>>>
>>>>Thank you. The challenge for me will be the columns for the fields that in the application are lookups. This makes the entry already validated. So, I will have to have some columns to be the drop-down (lookup). Other fields, which are free-format text, I don't need to worry about. And I agree that the updating multiple records could be a "hell". Another approach is to allow updating only the free-text columns.
>>>>But this is what a customer is asking and - probably -willing to pay for.
>>>
>>>you have to consider (at least)
>>>- Do you force the tableupdate, or do you respect changes?
>>>- if respecting changes to the base table:
>>> - what will you do if one record out of many fails
>>> - reject all
>>> - reject the one only
>>> - if rejected, you need to requery the changes from the base table (or you are unable to write) Then:
>>> - all records
>>> - those with a problem only
>>> - if reloaded,
>>> - will you add the changes made and not written to the records again, and mark the records with an problem
>>> - just show current state and mark the records with a problem
>>> - just notify the user about the problem
>>> - records with a problem may be deleted on the base table, that's special
>>>
>>>The engine to remember the changes and rewrite them alone is special.
>>>This does not cover changes from the base table and from your user that do not fit for some reason.
>>>It can be done by a generic machine (of the cursoradapter ...), except logic problems. Maybe for that you need an additional state of the record. Just to notify the user.
>>>
>>>This is all true for single records as well, but then I do not need to think about OTHER records too .... For a single record it is (just) refresh of the CA, and display the current value. User might remember data of a single, last, record. But many. Shudder.
>>
>>Thank you for much for the detailed list of items to consider.
>>
>>For me one more should be considered. Usually, when a user updates one record my BIZ object records which fields were changed, values before and after. When updating multiple records, I will need to account for these changes too (for each record). I don't know the details of how I will do it. Right now, I am just working on the time (cost) estimate of such a feature. I think once the customer sees the estimated cost, they may want to continue making changes one record at a time :)
>
>Fox already knows what fields changed on every row. Use getnextmodified to access the rows and getfldstate to check the columns.

Thank you.