No crrent record with empty subform

[Petr Danes]

I have a form with a subform in continuous view, sometimes the subform has
records to display, sometimes not.

There are command buttons in the header of the subform, because I want to be
able to do certain things even when there are no records. If I had them in
the body, they would not be visible when there were no records.

When I click any of the buttons, I get a pop-up saying "No current record".
I click OK and the dialog goes away, and the code under the button runs
normally. There is no code associated with the Current event, no events at
all associated with the form, body or header. No code or anything I have
created seems to be activated and the subsequent code from the command
buttons works fine. This error also occurs when there are no records and I
click "Design View".

Where can this error be originating?

Pete

 

[Marshall Barton]

I have a form with a subform in continuous view, sometimes the subform has
records to display, sometimes not.

There are command buttons in the header of the subform, because I want to be
able to do certain things even when there are no records. If I had them in
the body, they would not be visible when there were no records.

When I click any of the buttons, I get a pop-up saying "No current record".
I click OK and the dialog goes away, and the code under the button runs
normally. There is no code associated with the Current event, no events at
all associated with the form, body or header. No code or anything I have
created seems to be activated and the subsequent code from the command
buttons works fine. This error also occurs when there are no records and I
click "Design View".

Does the code behind the button refer to a value in the
details? If so, use a line like
If Me.Recordset.RecordCount > 0 Then
'do whatever
Else
'deal with no records situation
End If

 

[Petr Danes]

Does the code behind the button refer to a value in the
details? If so, use a line like
If Me.Recordset.RecordCount > 0 Then
'do whatever
Else
'deal with no records situation
End If

Some of it does, but I get the error message BEFORE the first line of the
button event code executes. I put a break point on the entry ( Public Sub
cmdXXX_Click() ) to the event routine. When I click the button, I get the
error message, click OK, and only then does the code break, and display the
VBE window.

 

[Marshall Barton]

Some of it does, but I get the error message BEFORE the first line of the
button event code executes. I put a break point on the entry ( Public Sub
cmdXXX_Click() ) to the event routine. When I click the button, I get the
error message, click OK, and only then does the code break, and display the
VBE window.

More details please. Post a Copy/Paste of the code and note
the line that's highlighted when the error occurs.

Usually, when you get an error message as the procedure is
called, before the first line of code, it means there is
something wrong with the code so the procedure can not be
processed. For example, one thing that can cause that is
when there is a compile error. Have you used the ebug -
Compile menu item while the form is in design view.

OTOH, if it does compile cleanly and nothing makes sense
when you run it, you should consider the possibility of
corruption. If that's what's happening, make sure you have
a backup before doing anything else just in case it gets so
bad the whole project is trash. The predominate cause od
code corruption is when you edit the code while the
form/report is not in design view, especially if you do not
compile it before switching back to form view.

 

[Petr Danes]

More details please. Post a Copy/Paste of the code and note
the line that's highlighted when the error occurs.

Well, I don't really know how much more detail I can provide. Again, the
error occurs BEFORE any of my code executes. When I put a breakpoint on the
first line of the event code, here:

Public Sub cmdXXX_Click()

I get the error, click OK to dismiss the error dialog and only AFTER that
does the VBE window appear with this line highlighted. But that that's not
the error line, it's a breakpoint and the error has already occurred and
been dismissed.

And as I mentioned earlier, I even get the error when clicking the form over
to design view, when the subform does not happen to be displaying any
records. Something about the subform not having any records is causing it to
throw this error, even when I'm not trying to take any action or execute any
code.

Usually, when you get an error message as the procedure is
called, before the first line of code, it means there is
something wrong with the code so the procedure can not be
processed. For example, one thing that can cause that is
when there is a compile error. Have you used the ebug -
Compile menu item while the form is in design view.

Yes, the all the code is compiled, I generally do a compile and save after
almost every edit.

OTOH, if it does compile cleanly and nothing makes sense
when you run it, you should consider the possibility of
corruption. If that's what's happening, make sure you have
a backup before doing anything else just in case it gets so
bad the whole project is trash.

I have compact and repair on close set, and I make copies including to other
machines, quite regularly. Almost every day I make a copy of the db and
archive it with the day's date as part of the name. I have such backup
copies going back for weeks, sometimes months.

The predominate cause od
code corruption is when you edit the code while the
form/report is not in design view, especially if you do not
compile it before switching back to form view.

Hm, okay, I didn't know that. I compile regularly, but I often do edit code
while in form view. You're saying that's a bad idea? I'm at home now (I'm in
Europe) and this db is at work, so I can try doing a decompile tomorrow.

This db has been -heavily- edited. If I spin the entire project over to a
new db file, wouldn't copying a corrupt form also copy the corruption? I
could re-create the entire problematic form if I had to, but I'd rather
not - it's quite complex. Would creating a new form and copying the controls
be better? Couldn't a control also be corrupt, and so copying the control
would copy the corruption? Where does corruption typically reside? The code
editor works with no errors, all the database forms and controls work fine,
just this one error for no apparent reason is cropping up.

Pete

 

[Marshall Barton]

Well, I don't really know how much more detail I can provide. Again, the
error occurs BEFORE any of my code executes. When I put a breakpoint on the
first line of the event code, here:

Public Sub cmdXXX_Click()

I get the error, click OK to dismiss the error dialog and only AFTER that
does the VBE window appear with this line highlighted. But that that's not
the error line, it's a breakpoint and the error has already occurred and
been dismissed.

And as I mentioned earlier, I even get the error when clicking the form over
to design view, when the subform does not happen to be displaying any
records. Something about the subform not having any records is causing it to
throw this error, even when I'm not trying to take any action or execute any
code.

I was thinking I might maybe attempt to spot something in
the code that might conceivably cause that error. Not much
more than a shot in the dark at this point.

Have you tried allowing the subform to display the new
record so the subform is not completely empty? If so, does
that make a difference?

Yes, the all the code is compiled, I generally do a compile and save after
almost every edit.



I have compact and repair on close set, and I make copies including to other
machines, quite regularly. Almost every day I make a copy of the db and
archive it with the day's date as part of the name. I have such backup
copies going back for weeks, sometimes months.



Hm, okay, I didn't know that. I compile regularly, but I often do edit code
while in form view. You're saying that's a bad idea

Yes, it is a bad idea. I have had code corruption occur
simply because I bumped the space bar while looking at a
form's code. The reason I know that was the cause is
because I had just decompiled, compacted, recompiled and
verified it all worked again. Then I inadvertently bumped
the space bar and it all went nuts again. SInce I became
very conscientious about switching to design view before
touching the keyboard, I have had very few code corruptions.

I'm at home now (I'm in
Europe) and this db is at work, so I can try doing a decompile tomorrow.

This db has been -heavily- edited. If I spin the entire project over to a
new db file, wouldn't copying a corrupt form also copy the corruption? I
could re-create the entire problematic form if I had to, but I'd rather
not - it's quite complex. Would creating a new form and copying the controls
be better? Couldn't a control also be corrupt, and so copying the control
would copy the corruption? Where does corruption typically reside? The code
editor works with no errors, all the database forms and controls work fine,
just this one error for no apparent reason is cropping up.

**IF** the code project is corrupted, then the easiest thing
to do is decompile. And yes, corrupted code can follow
along in an import everything. If the form is (also?)
corrupted then you should try decompiling, compacting and
then importing everything and finally (re)compiling. While
you do all that, hold down the Shift key to make certain
that there is no attempt to run any code (which will force
at least a partial compile).

 

[Petr Danes]

I was thinking I might maybe attempt to spot something in

the code that might conceivably cause that error. Not much
more than a shot in the dark at this point.

Have you tried allowing the subform to display the new
record so the subform is not completely empty? If so, does
that make a difference?

No, I hadn't before, but I did now, and it does make a difference. I don't
get the error when I allow additions on the subform, but that's not a
long-term solution. The subform is a summary of some details and is supposed
to be read-only. The button opens another form in dialog mode, which allows
editing of the one record that was current when the button was pressed. The
code that runs in the dialog form is quite involved, but once again, the
error occurs before any of it executes.

And another thing I just discovered, when the form is first opened, the
button to call the dialog form with an empty subform works fine, but only
once. It's only subsequent attempts that generate the error. Closing and
re-opening the form allows it to work again, once. Apparently, some sort of
change of state is happening, but I'm a but stumped as to what it could be.
If I was running some code that didn't work, I could see it and I believe
that I would be capable of tracking it down myself. But this error pops up
by itself, not as an error in code.

Yes, it is a bad idea. I have had code corruption occur
simply because I bumped the space bar while looking at a
form's code. The reason I know that was the cause is
because I had just decompiled, compacted, recompiled and
verified it all worked again. Then I inadvertently bumped
the space bar and it all went nuts again. SInce I became
very conscientious about switching to design view before
touching the keyboard, I have had very few code corruptions.

Rats, that's one of my favorite features in the VBE environment, and I use
it a LOT. Being able to change code and immediately seeing the effects,
without having to re-start the entire process is a huge advantage in
debugging and tuning. Do you know if 2007 is any better about that than
previous versions?

**IF** the code project is corrupted, then the easiest thing
to do is decompile. And yes, corrupted code can follow
along in an import everything. If the form is (also?)
corrupted then you should try decompiling, compacting and
then importing everything and finally (re)compiling. While
you do all that, hold down the Shift key to make certain
that there is no attempt to run any code (which will force
at least a partial compile).

Okay, I did all the de-compile, C&R, re-compile. No change, beyond what I
described above.

Pete

 

[Petr Danes]

I was thinking I might maybe attempt to spot something in
the code that might conceivably cause that error. Not much
more than a shot in the dark at this point.

Have you tried allowing the subform to display the new
record so the subform is not completely empty? If so, does
that make a difference?


Yes, it is a bad idea. I have had code corruption occur
simply because I bumped the space bar while looking at a
form's code. The reason I know that was the cause is
because I had just decompiled, compacted, recompiled and
verified it all worked again. Then I inadvertently bumped
the space bar and it all went nuts again. SInce I became
very conscientious about switching to design view before
touching the keyboard, I have had very few code corruptions.


**IF** the code project is corrupted, then the easiest thing
to do is decompile. And yes, corrupted code can follow
along in an import everything. If the form is (also?)
corrupted then you should try decompiling, compacting and
then importing everything and finally (re)compiling. While
you do all that, hold down the Shift key to make certain
that there is no attempt to run any code (which will force
at least a partial compile).

Okay, I've got it. The 'error AFTER one successful call' was what enabled me
to track it down. The dialog form is executing the call:

DoCmd.GoToRecord acDataForm, Name, acNewRec

which creates a record, but when that action is cancelled, this wasn't
getting reversed, which left the calling form in a confused state, which
caused the error to pop up, only later than the actual condition that
created it.

Many thanks, I can take from here.

Pete

 

[Marshall Barton]

No, I hadn't before, but I did now, and it does make a difference. I don't
get the error when I allow additions on the subform, but that's not a
long-term solution. The subform is a summary of some details and is supposed
to be read-only. The button opens another form in dialog mode, which allows
editing of the one record that was current when the button was pressed. The
code that runs in the dialog form is quite involved, but once again, the
error occurs before any of it executes.

And another thing I just discovered, when the form is first opened, the
button to call the dialog form with an empty subform works fine, but only
once. It's only subsequent attempts that generate the error. Closing and
re-opening the form allows it to work again, once. Apparently, some sort of
change of state is happening, but I'm a but stumped as to what it could be.
If I was running some code that didn't work, I could see it and I believe
that I would be capable of tracking it down myself. But this error pops up
by itself, not as an error in code.

This is sounding less and less like corruption. There has
got to be something odd about the code that is dependent on
the subform having a non empty recordset.

Rats, that's one of my favorite features in the VBE environment, and I use
it a LOT. Being able to change code and immediately seeing the effects,
without having to re-start the entire process is a huge advantage in
debugging and tuning. Do you know if 2007 is any better about that than
previous versions?

Every version is different, BUT the fundamental VBA code
library has had very few changes since A2000 so I would not
expect these issues to be solved.

These articles might help thin the fog about the complexity
of the problem:

This one is a classic oldie but goodie that was written by
Michka when he was a member of the Access development team.
http://www.trigeminal.com/usenet/usenet004.asp?1033

This one is pretty comprehensive. Item 2 is something
everyone needs to do because the symptoms are all over the
place. Item 3 may(?) be directly related to your problem,
corruption or not. Item 5 is directly relevent to our code
editing duscussion.
http://allenbrowne.com/ser-25.html

Okay, I did all the de-compile, C&R, re-compile. No change, beyond what I
described above.

As I said above, it's sounding less like a corruption issue.
Unfortunately that leaves us in the dark and I am just about
out of ideas.

 

[Marshall Barton]

Okay, I've got it. The 'error AFTER one successful call' was what enabled me
to track it down. The dialog form is executing the call:

DoCmd.GoToRecord acDataForm, Name, acNewRec

which creates a record, but when that action is cancelled, this wasn't
getting reversed, which left the calling form in a confused state, which
caused the error to pop up, only later than the actual condition that
created it.

Many thanks, I can take from here.

Great news. I was really getting frustrated too.

I guess the corruption discussion was just a distraction,
but probably worth the time.