Trying to salvage a report (1 Viewer)

[demax182]

So, I'm in the process of creating a database and have put a lot of focus on developing the reports. There is one particular report that causes MS Access to crash every time I attempt to open it. I can't open it in any of the views, including Design. I did research and attempted to decompile, compact & repair, and compile the database, but that didn't fix the issue. Next, I tried to import it to a new database, but that just leads to the new database crashing. Lastly, I tried the solution about removing binary data (several sites recommend this through my Google search).

However, I'm not quite certain on how to do that. I was able to save the report to a text file, but not sure exactly what to delete. The instructions say to delete anything that has the word "Parameter = Begin", but I don't see those words in the text file. I do see "GUID = Begin" a number of times, but not sure if I'm supposed to delete that? I do see the other lines that the instructions reference to like "NameMap = Begin", "PrtMip = Begin", etc..., but still unsure if I'm supposed to delete just the text between Begin and End. Or if I need to delete the whole thing. Fortunately I do have a kind of a back up, but unfortunately it's an older version... If I have to go back and rebuild what I have lost, then I guess it can't be helped... Any advice would be greatly appreciated.

 

[The_Doc_Man]

Do you have any VBA associated with the report?

I have to admit that being unable to open the report in design mode is kind of strange. Even worse, importing to another DB and having that fail is pretty bizarre.

We need to do some fact-finding. Do you get any error messages when this report takes down Access for you?

If this is Windows 10, try this: Be sure that the system clock is visible to you in the lower right corner of your screen in the task bar. Trigger this failed report and when it crashes, note that time to the minute.

Now using Win10, click on the Windows Icon (lower left) and click on the "gear" (settings). Now in the search box type "Control Panel" (without the quotes). From there you will want SYSTEM >> ADMINISTRATIVE TOOLS >>EVENT VIEWER. You will have at least a couple of event logs that you can test for actions. However, finding the right time is easy because the events are time-tagged and sorted chronologically. If you have a violent "death" of a utility program, you SHOULD have some kind of entry involving the MSACCESS.EXE process. You would be looking for the error code being reported for that crash. That code might help us.

 

[demax182]

Thanks for responding. There is VBA associated, but nothing terribly complex. They're if/then statements that determine the value of unbound check boxes. There is an unbound control that does call a function in a module. I don't know, but maybe that could be the problem. I have to admit, the report would crash every once in awhile, but just today, it became completely inaccessible. No error code, just the sliding green bar of death and a "Microsoft Access has stopped working" message box.

I was able to get into the event log per your instructions. I don't see an error code, but here are the details:

I did notice that the EventData mentions something about ACECORE.DLL. Could it be that this particular file is missing or corrupt? Thanks again for your help.

 

[The_Doc_Man]

If you can open the DB without opening the miscreant report, you can go into any code pages (Visual Basic page) via CTRL/G and check your references from there. If you use TOOLS>>REFERENCES you should be able to check the references.

Do you have ANY references that have either "Missing" or "Broken" as part of the line? If so, there is a serious problem with the missing/broken file. You might have to uncheck the reference and then attempt to recheck it, searching for a file of that name. The file ACECORE.DLL won't be in the references list, I think, because that is the ACE database engine subroutine library.

The actual error message is in there, but it isn't labeled. It is the line that reads "c0000005" - which is a fatal (untrapped and possibly untrappable) memory management violation. That occurs when you try to access an address that is not mapped or that is mapped but read-protected against you. More often than not, it is due to a bad subroutine linkage. I didn't see 0 address in the pile so it is not likely to be an undefined address based on anything YOU did. I.e. in design mode, you cannot do anything that would break an address linkage. You would have to willfully pass a zero by value to something expecting a by ref input. I cannot tell you more than that since Microsoft doesn't give us a map of their code that would be usable in tracing down this kind of thing.

Is there a chance that the app was developed on a 32 bit system and suddenly is on a 64 bit system (or worse, the other way around)?

 

[demax182]

I have 4 Available References checked, but none show "Missing" or "Broken" as part of the line. I don't think I created the database on a 32 bit system. The database was created on this company laptop, which is running on a 64 bit system. If IT were to change a 32 bit system to a 64 bit system, would that require a full install of the Operating System? My setup (shortcuts, wallpaper, installed programs, etc...) has been the same for a couple of years.

 

[Minty]

In addition to Doc's advice - try importing just the report into a new blank database.

See if you can then open it in that new database (in design mode only obviously).
If you can try saving it as another report with a different name.
Also, try deleting all the VBA from the report in the VBA editor.

 

[MajP]

That sounds like corruption to me. I would look at saving and loading the report from text. However I would also look at
1) Decompiling and recompiling
2) Importing into a new database
3) save and load from text
see discussion

Crash When Add Option Group

Hi, I am working on a form, everytime I add an Option Group with the value to store the selection to a table and save the form Access Crashes. If I create a new form I can create the option group no problem and save it. Can someone tell me why this might be happening? Thanks. Fen How

www.access-programmers.co.uk

It is always a good idea to routinely do number 2 above at the first time of corruption. I always do this after adding new features to the db. 1 might fix it and 3 might fix it, but it is always nice to do all of these and start clean.

 

[MajP]

FYI. That may sound like a lot of work to do that, but that is probably 30 mins for a new person and 10 for someone who has done it before.

 

[The_Doc_Man]

Guys, take a look at post #1, 1st paragraph. Demax182 has ALREADY tried the "export to new DB" and has done other things that relate to correcting some form of corruption.

My next guess is to try to do a "repair" on the installation of Access/Office. If the disk is available or the download is possible, it might help. I begin to suspect a corrupted install of Office, which means Demax182 is NEVER going to fix this by attacking the app. He has to address Access itself.

Demax182, I don't know if you have ever done this before and whether someone else in your organization would be the person to do this, but I believe there is something wrong with the installation of Access. The good news is that a "repair" option exists for Office installation kits, so if there is a way to try that, please do so. You might then have to go through some re-application of updates at the next Office update cycle, but that is normally done automatically anyway.

And sadly, corrupted installations are not unknown.

 

[Minty]

@The_Doc_Man My suggestion was to only import just the report to new database, not import the whole database.
It's something that I had success with when trying to recover a corrupt form that wouldn't work as soon as other database objects were about.

I agree with you about the Office repair as well, although perhaps they have tried opening it on another machine already.

 

[MajP]

Guys, take a look at post #1, 1st paragraph. Demax182 has ALREADY tried the "export to new DB" and has done other things that relate to correcting some form of corruption.
My next guess is to try to do a "repair" on the installation of Access/Office. If the disk is available or the download is possible, it might help. I begin to suspect a corrupted install of Office, which means Demax182 is NEVER going to fix this by attacking the app. He has to address Access itse

I completely disagree. There are certain corruption errors that cannot be fixed with either a decompile or an import into a new DB. As I pointed out in my post. If I had a single report that crashes the system, I for sure would save and load from text first before wasting time on an Access install.

 

[demax182]

Ok, so I had somebody from IT do a repair of the Access installation (this was done remotely as I do not have admin rights to install/uninstall/repair programs). The problem still persists. I've also tried importing the problem report to a clean database, but it causes Access to crash as well (no error message given). I've also tried to import the entire database into a clean database, but it crashes when it gets to the problem report. Took me awhile to figure out how to do it, but I saved the report to text (via VBA). Then loaded that same text file back into the database. The crashing still persisted.
A couple of sites through my Googling mentioned that corrupted binary data could be the problem. They provide direction on how to remove the binary data from the report (after it has been saved to text), but I'm still not fully clear to what extent I should delete. Even if I don't manage to salvage this report, thanks all for your feedback, I'm still learning a lot from all this troubleshooting.

 

[Micron]

Did you try opening the report in design view via vba? Probably would make no difference but at this point, what do you have to lose by trying?
From what I've read, you're supposed to delete all from Parameter to "End" for each block specified.

 

[The_Doc_Man]

Using that exported text to help you with the layout, delete the report. Copy the rest of the DB to a new file by going to the new file and IMPORTING the stuff you want from the old file. The basis for this is that if you have a crashing old file, something about it is bad. Importing to a new file means Access will not accidentally try to load that report. Then MANUALLY try to recreate the report based on your notes and that text item. Make backups every so often while doing this. The method to my madness is that if you try to touch something you shouldn't, it will go "bang zoom" on you - but you will have a recent enough backup to know that your were working with "XYZ" when things went crazy-town on you. You can reload your last backup and slowly add pieces-parts until you see what is happening and when.

 

[demax182]

Did you try opening the report in design view via vba? Probably would make no difference but at this point, what do you have to lose by trying?
From what I've read, you're supposed to delete all from Parameter to "End" for each block specified.

Still crashes when trying to open report in design view via vba.

 

[CJ_London]

Personally I suspect time is awasting and you will better reverting to a working earlier stage version of the report. Create a new db, import everything except that report then import your early stage report and bring it up to date.

Only other suggestion I have is with the report closed, open the vba window from the ribbon and see if you can navigate to the report module. If you can, copy paste the code to notepad, then try to delete the code. As soon as you change/delete any of the report code the report will attempt to open in design view.

If it doesn't and crashes Access - well something else you have tried which didn't work. But you can inspect the code to see if there is anything there which could be causing the problem.

if it does - go to the report properties and change the report hasModule property to false -you can do this from the properties window in the vba window if you wish. Next save and close the report. You might want at this point to decompile and compact/repair the db before moving to the next stage

Next reopen the report, select any event to get to the vba window and then delete the few lines of code created and copy/paste your code back from notepad (don't paste what you copied to notepad in the first place). Suggest comment out any event that is triggered as part of the report opening/formatting etc. If that all works, save the report and hopefully, job done - other than uncommenting any code you commented out.

 

[Galaxiom]

No error code, just the sliding green bar of death and a "Microsoft Access has stopped working" message box.

This might not mean Access has crashed, just that it isn't responding. Click Wait for Access to Respond if that is an alternative to closing Access and keep waiting. Sometimes it will get there in the end. Don't assume the green bar is proportional to the progress. Sometimes it can have gone nowhere for ages then suddenly jump to the end as records appear.

It could mean that the RecordSource query is chugging. Try deleting all the data in the tables the query is accessing.

 

[demax182]

Ok, so I'm manually recreating the report. Decided to call it the day and close out everything. Prompt comes up asking me if I want to save the report before closing it out. I select "Yes" and Access crashes on me again... I checked the Event Logger. Looks like a bit more info is provided on the error, but I don't know exactly what it means. Here's a screenshot:



This is all so aggravating... Thanks again everybody for your input.

 

[demax182]

This might not mean Access has crashed, just that it isn't responding. Click Wait for Access to Respond if that is an alternative to closing Access and keep waiting. Sometimes it will get there in the end. Don't assume the green bar is proportional to the progress. Sometimes it can have gone nowhere for ages then suddenly jump to the end as records appear.

It could mean that the RecordSource query is chugging. Try deleting all the data in the tables the query is accessing.

Understood, but Access restarts on its own shortly after the green bar of death and prompts me to choose a location to save a backup...

 

[Galaxiom]

Prompt comes up asking me if I want to save the report before closing it out. I select "Yes" and Access crashes on me again...

Could you be using a reserved word as the name of the report? The same name as the database will also cause trouble.