[AccessD] Access XP forms bound to ADO recordsets

Shamil Salakhetdinov shamil at users.mns.ru
Mon Mar 13 12:44:10 CST 2006


> 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

----- Original Message ----- 
From: "Steve Conklin" <developer at ultradnt.com>
To: "'Access Developers discussion and problem solving'" 
<accessd at databaseadvisors.com>
Sent: Monday, March 13, 2006 6:36 PM
Subject: Re: [AccessD] Access XP forms bound to ADO recordsets


>I have been following this thread with great interest.  When faced with 
>this
> issue, I have gone completely the opposite direction - that is not 
> bleeding
> edge but back to Access basics.  This was in an Access FE, MSSQL BE.
>
> 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, so all controls have the same name as
> fields.  The details in the subform (invoice line-items) are another 
> matter.
> After several failed attempts at a disconnected ADO recordset, I thought
> about arrays, dictionaries, collections, converting somehow ADO to DOA at
> runtime, but finally came back to Access iteslf - I had the best device 
> ever
> created for holding columns and rows of data:
> Access' own Tables!
>
> They provide nearly code-free storage, easy creation of new rows, are 
> easily
> displayed in bound sub forms, etc.
> I appended all the tbl_invoice_details to tbl_invoice_details_local - 
> which
> has the exact same structure, except that the pk-autonumber field in the
> local is neither.  It is a long with  a default of 0 (indicates new when
> writing back).  Also added a y/n field to indicate "deleted" (sub form
> filters for deleted=0).  This is decidedly low-tech as compared to
> serializing XML streams and such, and also requires home-grown locking (I
> added a bit field to invoice to indicate "in use"), but it does work by
> virtue of staying in Access sweet-spot rather than venturing in to 
> uncharted
> waters.
>
>
> Steve
>
<<< tail skipped>>> 




More information about the AccessD mailing list