Forms and ADO

[Ola Normann]

Hi all.

I am realy new to ADO, but I have decided that I have to try this..
I have read several books about access and vba with ado, but there are som
few(??) questions that I need answer on - just to start on the right foot..

First, I have one form I use as a switchboard, and som few subforms. The
subform uses separate tables for each form.

1: Where do i put the statements;
Dim rst As New ADODB.Recordset
Set rst.activeconnection = currentproject.connection
In the subforms open/load for each subform, or do I place them in the
"switchboard", making a unik name for each recordset needed for the whole
app?

2: Same for the rst.open.
Do I use one open for each subform(Open/load), or do I use the .open command
for each command on subform - eg. movefirst, movenext .... ?

3: On subforms; Do I use the rst.fieldname as control source, or do I
allways use the style like me.txtFirstname = rst.txtFirstname?

My problem is, I understand what I can do, but need som help on "how" and
particularly "where"...

Regards.

 

[RoyVidar]

Hi all.

I am realy new to ADO, but I have decided that I have to try this..
I have read several books about access and vba with ado, but there
are som few(??) questions that I need answer on - just to start on
the right foot..

First, I have one form I use as a switchboard, and som few subforms.
The subform uses separate tables for each form.

1: Where do i put the statements;
Dim rst As New ADODB.Recordset
Set rst.activeconnection = currentproject.connection
In the subforms open/load for each subform, or do I place them in the
"switchboard", making a unik name for each recordset needed for the
whole app?

2: Same for the rst.open.
Do I use one open for each subform(Open/load), or do I use the .open
command for each command on subform - eg. movefirst, movenext .... ?

3: On subforms; Do I use the rst.fieldname as control source, or do I
allways use the style like me.txtFirstname = rst.txtFirstname?

My problem is, I understand what I can do, but need som help on "how"
and particularly "where"...

Regards.

Heisan Ola!

I think what we struggle a bit with, isn't necessarily the "how" and
"where", but the "why".

In these groups, you will usually get the recommandation of using bound
forms (bind to table, query or dynamic SQL), and when using code, the
DAO object model.

If you could give us some details about why you think you need to go
unbound and use ADO, then perhaps some could assist.

 

[RoyVidar]

I think what we struggle a bit with, isn't necessarily the "how" and
"where", but the "why".

If you could give us some details about why you think you need to go
unbound and useADO, then perhaps some could assist.

The result of a quick google:

http://www.ukaug.co.uk/TPUnbound.asp

The Why Behind Unbound Data Forms

It is a simple fact that Unbound Forms require significant
programming effort when compared to normal Access forms, although you
could argue that after an initial investment of time the amount of
effort will decrease. So you need a good reason to do this. Some
reasons for following this path are as follows: -

You find yourself having to work around, or subvert many of the
features of Access forms, such as automatically saving records.
Performance is critical in manipulating data from a Server Database.
You want to take explicit control of record locking mechanisms.
You want a development strategy which is closer to that of .NET or
VB.
You want good scalability, against possibly different Server
Back-ends (Access, SQLServer, Oracle, MVS...).
You find yourself fighting against a number of default behaviours in
Access.
Now I am not saying that some of the above requirements can not be
met using bound forms, but if you follow the spirit of these
requirement then you will be drawn to use Unbound Forms.
[Unquote]

Jamie.

I was asking the OP why *they* thought they need to use ADO and unbound
forms.

My experience is that often when people wish to go unbound with Access,
the reason is that they don't understand how Access works, the sequence
of events, different properties, behaviour etc, and they want to work
around default Access behaviour. My recommandation, unless it was one
of these rare situations where unbound could be more appropriate (which
I intended to find out by asking the OP), would usually be to either
learn how Access works or choose a different/more appropriate tool.

I thought the reason you don't use bound forms, was that you've chosen
the latter, not using Access at all.

BTW - you are aware that binding forms to ADO recordset, which is
indicated in the initial post, poses some challenges with the 2000
version and Jet data? I would call that reduced scalability compared
to ordinary bound forms or DAO.