[AccessD] Access XP forms bound to ADO recordsets

Yes, we're serious :) - here is promised first version of the crash test:

http://smsconsulting.spb.ru/download/tests/a2dds.htm

It seems to work well.

Enjoy!

Shamil

P.S. That wasn't easy night!....

----- Original Message ----- 
From: "John Colby" <jwcolby at ColbyConsulting.com>
To: "'Access Developers discussion and problem solving'" 
<accessd at databaseadvisors.com>
Sent: Tuesday, March 14, 2006 1:47 AM
Subject: Re: [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
>
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com