[AccessD] Access XP forms bound to ADO recordsets

>I haven't asked John to approve this statement but I expect he will agree

So true, very serious.  ;-)


John W. Colby
www.ColbyConsulting.com 


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: Monday, March 13, 2006 1:44 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Access XP forms bound to ADO recordsets

> Doing unbound in a "header" record (invoice, for instance) is pretty 
> straightforward, especially when starting with a bound form and then 
> deleting the record source property
Steve,

Myself and John are bounders and we are very serious guys ;) I haven't asked
John to approve this statement but I expect he will agree - am I right,
John? :)

So we are talking here about bound forms (and reports) but bound to ADODB
recordsets.
Just to make it clear what is discussed in this thread  - this is a
technique partially described here - http://support.microsoft.com/kb/281998.

The difference we are talking about is that we are "exploring the waters" of
MS Access forms bound to DISCONNECTED ADODB recordsets. The purpose to do
that is to have backend DB(s)unlocked (not even touched by MS Access FE)
while the extracted data are edited in MS Access form with subform(s) when
both form and its subform(s) may have potentially many rows, which we can
edit using built-in MS Access features and then post ALL the changes back at
once in an ADODB "AUTOMAGIC" BATH UPDATE or in manually prepared batch
update in one transaction etc. (There are other implied very useful features
as serializing/transmitting/deserializing/storing/.. batch updates, having
light-weight MS Access FEs etc. - but all that will make sense to discuss
only when the main technique will start to work stable enough to be used in
real life applications.)

> I had the best device ever created for holding columns and rows of 
> data: Access' own Tables!
True - I did write such code a long ago for MS Access 97, many others did do
that - the difference we're talking about is that we wanted to use bound
forms but  we do not want to be bound to MS Access (local) tables and we
wanted to have as little as possible custom coding and if have such coding
then rather generic and flexible and scalable.

>  and also requires home-grown locking (I added a bit field to invoice 
> to indicate "in use"),
Yes, it will need to use something like that of course - and this is always
needed for the optimistic locking, e.g. when one is working in fully unbound
mode in VB6 or C#/VB.NET/C++....

Shamil