>>>>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 :)
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham