[AccessD] Redesign the problem to fit the solution

Charlotte,

I am (finally) looking at the demo.  While it is interesting 
in its own right it does not write the data back to the 
database but to a file.  The "persisted" data is a file correct?

I am actually interested in ADO disconnected technology to 
store the data in the controls, allow updates back to that 
disconnected recordset, and then when the edits are 
finished, perhaps use the ADO recordset to write back to the 
data table.

The form would still be unbound, and the disconnected ADO 
record would provide a "storage" location with which to 
compare "original" to modified (find modified values), as 
well as compare "original" to "what is in the table now" 
(other user edits stored before you got your write.  If you 
think about multi user issues, it doesn't matter if a record 
was modified by another user as long as the fields YOU 
EDITED were not modified.  Thus the only time you have an 
issue is in those cases.  This cuts down the number of 
"record edited by another user" messages to only those cases 
where you both edited the same FIELD in the same record.  In 
some cases that would make an immense difference.

Your solution does indeed read and write data but it 
completely skirts around real life, multi-user issues.

I understand the whole "field name in the tag" thing, though 
I wouldn't use that.  I would go with a naming convention I 
think, but the concepts are identical from there.  Find the 
field to load and load it into the control.  Find the field 
to unload and load it out of the form.

The concepts of persisting a table to a file is cool and 
definitely the subject of another thread.  One thing I have 
been looking for (in VB.Net) is now to persist to XML WITH 
field information.  .Net has built in persistence but AFAICT 
it only dumps the field name and value.  I would like to 
dump field name, data type and value.  THAT would provide 
the ability to send data to other applications with 
sufficient information to do more than guess about the data.

But that is for another thread and probably another list as 
well.

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