[AccessD] Redesign the problem to fit the solution

jwcolby jwcolby at colbyconsulting.com
Thu May 29 14:23:33 CDT 2008


Charlotte,

If and when I get around to this kind of solution I would:

1) Create a data store for the data coming from the record 
to manipulate.  Call this Original Read.
2) Create a system for automatically matching field to 
control.  In my mind, probably a control naming convention 
such that the field name is embedded in the control name? 
Something like that.
3) Read the data from the data store into unbound controls, 
leaving the original record untouched.
4) Allow the user to edit away.
5) Create some method to allow the user to signal "edit 
complete.
6) Compare original data to control data.  IF any changes 
were made then...
7) Pull the same data record from the table into a NEW data 
store.  Call this Compare Read.
8) Compare Original Read data to Compare Read data to 
discover if any data was edited.  IF NOT then LOCK the 
record in the table at this point.  If NO field collisions 
between Compare data and Modified Data (form) then LOCK the 
record in the table at this point/
9) Create a third data record.  Call this Write Data.
10) Copy Compare Read to Write Data.
11) Update fields with modified data from the controls
12) Write the Write Data back to the table, releasing the lock

If there were edits between Original Read and Compare Read 
AND the modified fields collide with Compare read fields 
THEN error handle.  The error handler would need further 
thought.  Notify the user and allow overwrite?  Notify the 
user and trash changes?  Notify the user and store in some 
temp location for conflict resolution?

For a generic solution there would have to be system 
specific rules, i.e. in this system we want the users to be 
told and made to reenter the data (trash changes).

John W. Colby
www.ColbyConsulting.com


Charlotte Foust wrote:
> Then I have to point out AGAIN that the demo I suggested does exactly
> what you wanted, but only for a single "table" and with a predesigned
> field layout in the UI.  Allows you to edit/add/delete records in an
> unbound form.  It does NOT allow you to do it for any record in any
> table, that is an exercise left for the student. ;->   You would
> probably want to use a grid if you wanted to handle "any table" and
> define the columns on the fly based on an ado recordset.
> 
> Charlotte Foust




More information about the AccessD mailing list