[AccessD] Redesign the problem to fit the solution

In the demo, the persisted data was to either an xml file or an ADTG(?)
file, but that's only because the demo was on persisted recordsets.  All
the unbound manipulation is the same regardless of whether you populate
the recordset from a table or a file.  The file becomes, in effect, the
table.

Charlotte Foust 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Thursday, May 29, 2008 11:56 AM
To: Access Developers discussion and problem solving
Subject: Re: [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

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com