[AccessD] Redesign the problem to fit the solution

jwcolby jwcolby at colbyconsulting.com
Fri May 30 08:20:52 CDT 2008


 > So? Trash Access??

The client has 6 years and 175K invested in the Access 
solution....

I would love to do so though.  ;-)

John W. Colby
www.ColbyConsulting.com


Gustav Brock wrote:
> Hi John
> 
> What you describe here is close to how a DataGridView with a DataTable and a DataTableAdapter as the source in .Net.
> 
> So? Trash Access??
> 
> /gustav
> 
>>>> jwcolby at colbyconsulting.com 29-05-2008 21:23 >>>
> 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