[AccessD] Access XP forms bound to ADO recordsets

> Perhaps it is time for other influentials (you and I and this list) to
> revisit this feature and see if it can be used now?
Yes, John, we may try to do that together with AccessD group.
But we may get stack trying to find how to use it without MS Access
crashing.
Please take that into account before proceeding with this risky
(ad)venture - I do have a simple crash test here already based on Northwind
sample and MS SQL database. And it does do crash MS Access 2003 well when
working with MS SQL backends.
And I do think I know why. And for this problem there seems exisiting a
simple workaround.
But I have to test it more. And it seems to always work well for MS Access
2003 backend.

Yes, I see I use "seems" to often - I'm still unsure it will work stable.

And of course some things have to be programemd differently - e.g. Pivot 
forms do not work at all, or using built-in delete have to be worked around 
differently than it's usually done with bound forms. Reports work only with 
ADPs - the trick is to use empty disconnected ADPs....

It does crash when MS SQL 2000 is a back-end and THIS IS IMPORTANT - when
VBA code is used to assign controls' values - this is exactly what Steve
experienced. But there exists a simple workaround as far as I noted above.

I did try the crash test with empty ADP FE as well - the same effect: it
works well with MDB backends and crashes with MS SQL 2000 backends when
setting control values in code without workaround....

Today is Monday, the 13th, I don't know how there on the West but here in
Russia, Monday, the 13th is considered as not good day to work - maybe
Access crashes because of that :)

I will publish the crash test and teh code tomorrow.
I have to do some real life work today.

Everybody interested to find workarounds for other problems to come  are
very welcome! Please make back-ups of your Northwind MS SQL 2000
sample database...

Maybe we together can talk directly to MS Access Team
(http://blogs.msdn.com/access/) to force them to make this feature working
stable without any workarounds at least in MS Access 12? Probabilty is
low but it's worth trying I think?

Shamil


----- Original Message ----- 
From: "John Colby" <jwcolby at ColbyConsulting.com>
To: "'Access Developers discussion and problem solving'"
<accessd at databaseadvisors.com>
Sent: Monday, March 13, 2006 3:43 PM
Subject: Re: [AccessD] Access XP forms bound to ADO recordsets


> What I am asking though is whether RecordsetClone still exists, and is
> somehow populated from whatever data source the form is bound to?  After
> binding to an ADO recordset, attempts to access RecordsetClone throw an
> error "Type mismatch" on the line of code
>
>        Set mrst = mfrm.RecordsetClone
>
> Mrst is defined in the class header as a DAO recordset.
>
> I might be able to get away with generalizing mrst to an object.
>
> NOTE: I tried that, and while the "Set" now works, the objects have
> different methods so any code using the object has to have different code
> paths written.  So apparently RecordsetClone is indeed initialized as an
> ADO
> recordset which makes all of my DAO specific code (FindFirst for example)
> throw a runtime error if encountered.  If I am going to do this, I will
> need
> to branch my code based on the Access Version as well as whether I
> actually
> used the ADO recordset code.
>
>>Please do not spend a lot of time on it now or at least do not plan to
> broadly use it in your development until
>
> Luckily, in my framework, I can turn on and off capabilities by examining
> SysVars.  It does sound like the instability objections were from an early
> adopter.  Like most things in Software, trying to use any specific feature
> in Access in the early stages of its introduction can be risky.  It is
> possible (and hopefully true) that they found and fixed the bugs causing
> such instability.  One of the problems with influential early adopters is
> that people read their warnings and never use a feature because they
> reported it unstable.  If they never go back to revisit it, then it is
> forever labeled unstable.
>
> Perhaps it is time for other influentials (you and I and this list) to
> revisit this feature and see if it can be used now?
>
> John W. Colby
> www.ColbyConsulting.com
>

<<< tail skipped >>>