Cannot create Recordset Clone

[oldblindpew]

I'm getting error #2467: "The expression you entered refers to an object that
is closed or doesn't exist."

This error occurs on the following line of code:
Set rst = Me.Recordset.Clone

The form is open, and has a table as its RecordSource. The table has data
in it.
I have Dim rst As DAO.Recordset.

The database was originally created under an older version of Access, and is
an mdb file. I have added DAO 3.6 to the references.

I have run repair and compact.

Could the problem be that the Sub is Private instead of Public?
Could it be that it is an mdb file?

If you want the whole awful story, look for a thread called "Somebody Please
Help Me" in Forms Design.

Any help would be appreciated.

 

[Stuart McCall]

I'm getting error #2467: "The expression you entered refers to an object
that
is closed or doesn't exist."

This error occurs on the following line of code:
Set rst = Me.Recordset.Clone

The form is open, and has a table as its RecordSource. The table has data
in it.
I have Dim rst As DAO.Recordset.

The database was originally created under an older version of Access, and
is
an mdb file. I have added DAO 3.6 to the references.

I have run repair and compact.

Could the problem be that the Sub is Private instead of Public?
Could it be that it is an mdb file?

If you want the whole awful story, look for a thread called "Somebody
Please
Help Me" in Forms Design.

Any help would be appreciated.

Lose the second period. IOW make the line read:

Set rst = Me.RecordsetClone

 

[John W. Vinson]

I'm getting error #2467: "The expression you entered refers to an object that
is closed or doesn't exist."

This error occurs on the following line of code:
Set rst = Me.Recordset.Clone

The form is open, and has a table as its RecordSource. The table has data
in it.
I have Dim rst As DAO.Recordset.

The database was originally created under an older version of Access, and is
an mdb file. I have added DAO 3.6 to the references.

I have run repair and compact.

Could the problem be that the Sub is Private instead of Public?
Could it be that it is an mdb file?

If you want the whole awful story, look for a thread called "Somebody Please
Help Me" in Forms Design.

Any help would be appreciated.

Make it RecordsetClone (with no period) if you're using DAO. It's confusing;
the Recordset.Clone syntax applies to ADO.

And please accept my apologies for my snippy answer this morning - I shouldn't
have been on the boards at all with the mood I was in, and I'm sorry.

 

[oldblindpew]

John,
Sorry, the dot in "Recordset.Clone" was just a typo in my posting. This
incorrect syntax was never actually present in my code.

Here's what was really happening: I didn't understand that "Me" refers, not
to the active form, but to the form in which my code runs, in this case, a
dialog form. I assumed, not unreasonably IMO, that closing the dialog form
would cause the underlying maintenance form to become the new "Me". So
trying to create a recordset clone after having closed the dialog form
resulted in Access telling me that the referenced object ("Me") was either
closed or non-existent.

On the other hand, if I left the dialog form open, I got an error because
the dialog form itself has no RecordSource from which to create a recordset
clone.

The solution was in replacing "Me" with a specific reference to the name of
the underlying maintenance form for which I wanted a recordset clone.

IMO, this makes "Me" less useful. The idea, I thought, was to help Access
to be more context-aware so we could concentrate more on procedures instead
of staying bogged down in identifying objects all the time.

In my application, I was using the same dialog form with the same event
procedure to find a firm for several different maintenance forms. Now my
procedure has the name of a specific form hard-coded into it, so it is
"married" to that one form. I seem to find myself getting painted into these
kinds of corners all the time with Access. The power of a subroutine is to
run the same bit of code with different arguments to get different results.
In Access I have to have multiple copies of the same bit of code, each with
different embedded references. I don't see this as an improvement over the
"bad old days" of procedural programming.

 

[Bob Quintal]

=?Utf-8?B?b2xkYmxpbmRwZXc=?= <[email protected]>
wrote in

In my application, I was using the same dialog form with the same
event procedure to find a firm for several different maintenance
forms. Now my procedure has the name of a specific form
hard-coded into it, so it is "married" to that one form. I seem
to find myself getting painted into these kinds of corners all the
time with Access. The power of a subroutine is to run the same
bit of code with different arguments to get different results.
In Access I have to have multiple copies of the same bit of code,
each with different embedded references. I don't see this as an
improvement over the "bad old days" of procedural programming.

Instead of binding the dialog form to a specific parent form, pass
the name of the calling form in the openargs parameter, and use that
to set the correct formname in the set rst line.

Something like
in the mainform:
docmd.openform "MyDialog" openargs:= Me.name

in the dialog form:
set rst = (openargs)recordsetclone