why does wizard write this code

[Rod]

When I use a wizard to set up a combo box it writes the following code.

Why does it use an object rather than a recordset and why does it not close
the object after it has finished?
Am I missing something or is it just sloppy?

cheers

Rod
--------------------------
Private Sub FindOnLocation_AfterUpdate()

' Find the record that matches the control.
Dim rs As Object

Set rs = Me.Recordset.Clone
rs.FindFirst "[Task ID] = " & Str(Nz(Me![FindOnLocation], 0))
If Not rs.EOF Then Me.Bookmark = rs.Bookmark

End Sub

 

[Guest]

H

I wouldn't worry to much... but yes: the wizards do write "dirty code". Elegant it may not be, but work it does

I am not sure on the technical details, but it creates copy of the recorset, and assigns it to the object variable. It does not work directly with the record

David

 

[Mark Phillipson]

It may have to do with ADO and DAO recorsets and Projects (*.adp) and
Databases (*.mdb)

 

[Neil]

Hello Rod,

AFAIK, Access has DAO as the default recordset for Access97 and earlier and
ADO is default for Access2000 onwards. The code below (i think) would work
in all of these Access databases as no recordset type is declared (just an
object). It is just a way to declare a 'broader range' of objects instead of
a specific object. Just like defining Control instead of Textbox. I was also
told (cant remember by who) that when a sub routine finishes, it *should*
set objects to be nothing automatically (and would also close the recordset)
so you dont need to add these lines to your code, programmers normally code
this themselves as an extra precaution. Therefore, although it does look
sloppy, it can be used a lot more than specifying a recordset type.

HTH,

Neil.

 

[Dirk Goldgar]

When I use a wizard to set up a combo box it writes the following
code.

Why does it use an object rather than a recordset and why does it not
close the object after it has finished?
Am I missing something or is it just sloppy?

cheers

Rod
--------------------------
Private Sub FindOnLocation_AfterUpdate()

' Find the record that matches the control.
Dim rs As Object

Set rs = Me.Recordset.Clone
rs.FindFirst "[Task ID] = " & Str(Nz(Me![FindOnLocation], 0))
If Not rs.EOF Then Me.Bookmark = rs.Bookmark

End Sub

It's not sloppy; it's an attempt to cover the variety of ways Access
can be used. By using late binding ("Dim rs As Object"), the wizard's
code can be applied regardless of whether the form's Recordset property
returns a DAO or ADO recordset, or for that matter *any* object that
supports the Clone and FindFirst methods and EOF and Bookmark
properties.

It doesn't close the rs object because it didn't open the object, but
rather acquired it by "cloning". It's generally considered good
practice to close what you open, and not close what you don't open. It
*might* have explicitly set the rs object to Nothing, although it should
automatically be destroyed when it goes out of scope. I try to make it
a habit to explicitly destroy object variables, as there have been
occasional reports in the past (apocryphal, as far as I'm concerned) of
objects not being properly destroyed. That's what most people I know
do, but some very knowledgeable people have said that if you have to do
this, VB must be seriously broken.