access crashes every time I do this

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a form with a print button. It brings up a print preview. When I close
the print preview the form is back on the screen. If I click the scroll bar
it will crash Access every time. I can reproduce the error at will. This is a
show stopper for my application and I already posted a question about this a
few days ago. Can someone please help.
 
This is probably some form of corruption.
What version of Access? And which service pack?

To rebuild it, try this sequence:
1. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
Explanation of why:
http://members.iinet.net.au/~allenbrowne/bug-03.html

2. Compact the database:
Tools | Database Utilities | Compact.

3. Decompile a copy of the database by entering something like this at the
command prompt while Access is not running. It is all one line, and include
the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

4. Compact again.

That may be all you need to do. If it is still faulting at this point, the
next step would be to follow the 5 steps for the first symptom in article:
Recovering from Corruption
at:
http://members.iinet.net.au/~allenbrowne/ser-47.html
 
Hi Allen,

I appreciate the information, but I can recreate this and have with a
database with no data in it. I actually found out a little more today. If I
open a report preview from a button on a form and then go to the scroll bar
on the fom and click, Access will crash whether the report preview was closed
or not. If I click anywhere else first the crash does not happen.

The probelm happens on both Office 2003 and Office 2000. I have the
Professional Edition.

Thanks, Caryl
 
Okay: you are narrowing this down.

The report had no data, but still crashed.
Can I assume that it had no RecordSource at all?
If so, it is clearly not a JET problem, and is starting to sound like a
Windows problem or bad video driver.

To test if Windows XP is a factor:
If you are using Windows XP, close Access, right-click on the desktop, and
choose Properties. Set the Theme to "Windows Classic". Then test the report
again.

To test if the video driver is the problem:
Right-click the desktop, and choose:
Properties | Settings | Advanced | Troubleshoot
Set Hardware acceleration to None.

If you can't find the settings there, or are using a different version of
Windows, go to the Control Panel, and try under Display Settings.

It would be worth checking out if you can get an updated driver for your
video card anyway.

Hopefully that line of investigation will help track down the cause.
 
Hi Allen,

The probelm exists on 5 different computers. I know for sure that 3 of them
are totally differnet. I have a Dell 8600 laptop and two of them are
different types of desktops. I can make it happen remotely on one of the
computers as well using GoToMyPC.

The error I get is:

AppName: msaccess.exe AppVer: 11.0.6355.0 AppStamp:40aa97a8
ModName: user32.dll ModVer: 5.1.2600.1255 ModStamp:3f731c7d
fDebug: 0 Offset: 0000461d

Does this help? In my recreation of the problem to isolate it, I have no
tables, just a form with 2 subforms and one report. None of them attempt to
access a recordset.

I am so stuck!
 
This sounds, serious, and I can certainly understand your frustration.

I'm not clear what the common element is here. You say it happens on
different machines, and in at least 2 versions of Access, and in a database
with and without data.

We need to pin this down. Questions:
1. Does it happen on *any* report in *any* database?
For example does it happen with the reports in Northwind?
Or is it just specific to this ONE database?

2. What operating system? Are all these machines running Win XP?

For now, we will ignore the video driver question. The laptop and desktops
would have different video cards/drivers, so that appears not to be a
factor.

Office 11.0.6355.0 is 2003 with SP1 (I think) so Office service packs are up
to date.
 
To add to Allen's questions -

Are all these machines networked?

Do they share a network printer? Do you have a default
printer set in Windows?

Are you using the same antivirus on all these machines? Is
it on all the time?

Did you install Office from the same cd or admin install set
to all these machines?

Are all these machines running a firewall (zone alarm or
whatever)?
 
Hi Allen and Nick,

I have run it myself on another desktop running Windows 98 and Office 2000,
so the problem exists on Office versions 2000 and 2003 and Windows versions
98, 2000 and XP Pro on both desktops and laptops. The machines are on
different LANS or even off the net all by their lonesome. One is running
Norton Anti-Virus with current definitions, one has Norton loaded, but the
definitions are over a year old. (It is not used on the internet) The other
computers are in other states and I am not sure what versions of everything
are running on them. I have a Windows 2000 machine I could try tomorrow as
well, but my friend told me he is seeing it there as well.

Here is the error on the 98 machine:

MSACCESS caused an invalid page fault in
module USER32.DLL at 017f:bff55472.
Registers:
EAX=0000001c CS=017f EIP=bff55472 EFLGS=00010202
EBX=00000000 SS=0187 ESP=0062efc8 EBP=0062efd0
ECX=00000918 DS=0187 ESI=0000001c FS=4b2f
EDX=00000000 ES=0187 EDI=000008fc GS=0000
Bytes at CS:EIP:
ad 3b c8 7c 10 ad 3b d0 7c 0b ad 3b c8 7d 06 ad
Stack dump:
00000000 0062f7a8 0062eff0 301576bb 0000001c 00000918 00000000 00000914
0062f974 0062f95c 0062f89c 3022451b 00000918 00000000 00000001 00000000


Originally the error was seen during QA on a new system being developed with
lots of data in the database. This is a migration from Excel to Access. In
order to isolate and reproduce it I wrote a small program that only has the
problem by itself.

There is no network printer, but I have a printer I can attach to any of the
machines.

Access was installed in different years from different CDs.

My laptop has current service patches and updates. The Windows 98 machine
does not.

I wish I could attach it here because the mdb file is only about 112K

Thanks,

Caryl Rahn
 
Is it only one report that causes the problem?
Or is it all reports in this database?
Or is it all reports in all database (even Northwind)?
 
Hi Allen and Nick,

I answered all the questions when I replied to Nick's
post. Since I cannot fix the Access program, is it
possible for me to make the program simulate the user
performing another action prior to clicking on the scroll
bar. Since the crash does not happen if they click on the
main window first floowed by the click on the scroll bar,
would I be able to simulate that?

Thanks
Caryl
 
Okay: perhaps I'm not seeing one of your replies, as I don't know if it it
one single report that does this (even if imported into a 2nd mdb), or if
you see it with any report you open in Access.

Given what we do know, I still supect that it is a corruption, and could be
fixed by recovery techniques.

Trying to simulate a mouse click doesn't sound like a great workaround. You
can use SelectObject to force the Database to take focus, and SetFocus to
switch back to the report preview, but that may not solve the issue if it
mouse-related, and won't solve it if it is a corruption.

A2003 is very stable, apart from corruptions, Name AutoCorrect, foreign keys
in subform not represented by a control, and some stacked queries that
contain subqueries. With the information we currently have, I'm not sure
which of those directions to suggest investigating.
 
In Northwind there is nothing that is the same as this. If you open the Sales
Reports Dialog and choose to preview one of those reports it closes the
dialog box. If it did not close the dialog box it would be more like mine and
would allow the user to click on the scroll bar. My form does not close when
you click on Preview, it stays up in the background.

Thanks,
 
carylrahn said:
I wish I could attach it here because the mdb file is only about 112K
Click to expand...

I can't reproduce the problem from yuor description, in my own test
database. If you'd like to send me your test database, I'll see if it
misbehaves for me (time permitting). You can send it to the address
derived by removing NO SPAM from the reply address of this message.
 
Hi Dirk,

I sent you the file to your email as requested. Let me know if you do not
get it.

Thanks,
Caryl
 
Hi Allen,

I missed this post earlier today. I can create more reports that do this. I
have reproduced the problem in a small file and know that there is no
corruption. There are no tables in my little DB I created to reproduce the
problem. I am pulling out my hair with this. I have not recreated this on 3
computers in my house, with differnet OS's and different versions of Access.
This is in addition to 3 other computers at other sites. where I or someone
else recreated the problem. I believe all the other sites were running
Windows XP and Office 2000.

Thanks,
 
Caryl, take Dirk up on his offer. He's good.
If he's not able to look at it, email me.
You can deduce my address from the sig below.
 
carylrahn said:
Hi Dirk,

I sent you the file to your email as requested. Let me know if you do
not get it.
Click to expand...

Got it, Caryl, and I see what's happening. You didn't mention
everything that you are doing on that form. You have the following
event procedures relating to the subform controls on that form:

Private Sub sfA_Enter()
Me.sfB.SourceObject = "fBlank"
Me.sfA.SourceObject = "fA"
End Sub

Private Sub sfB_Enter()
Me.sfA.SourceObject = "fBlank"
Me.sfB.SourceObject = "fB"
End Sub

In other words, you are using the Enter event of the subform control to
reset the subform control's SourceObject property. That's a bit odd, to
my way of thinking, but that alone wouldn't be crashing Access. But
when you click the Print button (not on the subform) to open the report,
then close the report and click the scroll bar on the subform, the Enter
event of the subform control fires again. That leaves the subform
trying to process the scroll message, at the same time the Enter event
is trying to replace it with ... itself. Apparently Access gets
hopelessly confused at this point, and crashes. Any time the program
crashes, it's a bug, of course -- but I'm not really surprised at this
one.

Was it your intention to swap subforms as you switch pages? I would
just use the tab control's Change event for that; e.g.,

Private Sub TabCtl0_Change()

Select Case Me.TabCtl0.Value
Case 0
Me.sfB.SourceObject = "fBlank"
Me.sfA.SourceObject = "fA"
Case 1
Me.sfA.SourceObject = "fBlank"
Me.sfB.SourceObject = "fB"
End Select

End Sub

Then, since the first page is going to be the initial value of the tab
control, I'd set the initial SourceObject of sfA to "fA", so that "fA"
will be displayed when the form first opens. I believe this approach
will put an end to your crashes while giving you what I think you want.

If, on the other hand, you want to continue with your current approach,
you can put an If statement into your Enter event procedures to
forestall the problem:

Private Sub sfA_Enter()
If Me.sfA.SourceObject <> "fA" Then
Me.sfB.SourceObject = "fBlank"
Me.sfA.SourceObject = "fA"
End If
End Sub

Private Sub sfB_Enter()
If Me.sfA.SourceObject <> "fB" Then
Me.sfA.SourceObject = "fBlank"
Me.sfB.SourceObject = "fB"
End If
End Sub

However, I really think using the tab control's Change event is the
better way to go.
 
Hi Caryl.

I also received a copy of your database. The crash nothing to do with the
reports. It occurs because you changing the SourceObject of the subform
control in its Enter event.

If the subform control has a scrollbar, and that's where you clicked, Access
has to respond to the click. Presumably it tries to scroll down. However,
the Enter event causes whatever object is in the subform control to
disappear, and loads an object, which may or may not need a scrollbar, so
Access is now trying to scroll down an object that is in the process of
disappearing and being replaced. It is not really surprising to see it crash
under those circumstances.

The workaround is to set the SourceObject of the subform control in the
Change event of the tab control, instead of the Enter event of the subform
control. This kind of thing:

Private Sub TabCtl0_Change()
Select Case Me.TabCtl0.Value
Case Me.Page1.PageIndex
If Me.sfA.SourceObject = "fA" Then
'do nothing
Else
Me.sfA.SourceObject = "fA"
End If
Case Me.Page2.PageIndex
If Me.sfB.SourceObject = "fB" Then
'do nothing
Else
Me.sfB.SourceObject = "fB"
End If
Case Else
MsgBox "Tab " & Me.TabCtl0.Value & " not handled."
End Select
End Sub

Private Sub Form_Load()
Call TabCtl0_Change
End Sub
 
Back
Top