Compile, Crash, Scream

[Guest]

Hi
I'm have a serious issue with a database I'm developing for a customer who is anxious for it to be completed. The problem...well, the symptom of the problem, is very clear. When I run the compiler in the VBA window, the compiler progress bar gets about 3/4 through compiling, then Access completely crashes. I've had the problem on 2 different machines (on the same MDB file under development).

I'm really stuck. I don't have a clue. I'm not sure if exporting all objects from the MDB file into a new, blank database might help. I've been building Access and SQL Server databases for years, but this is a real nasty problem. I thought it might just be the machine until I tried it on another and had the same problem. I can't open a support incident with Microsoft because it costs too much money (WAY too much)

Here's the specifics: I'm running Access XP, SP3. The machines I've experienced the crashes on are Windows XP Pro and Windows 2000 Pro. I'm not using any 3rd party objects or libraries in the project. The database is split into front and back end. About the most "extravagant" objects in the design are a couple of forms that have Excel spreadsheets embedded in them. I'm using other Microsoft objects like Date Time Picker controls and Progress Bars

If anyone has any suggestions (besides going into another line of work), I'd be grateful

Thanks
PaulJS

 

[RobFMS]

I realized this may be a bit sideways, but remove the embedded excel
spreadshets, DataTime picker and progress bar controls from your application
for a short period of time and see how your application works. In other
words, create a new .mdb and import all the objects except those that
contain the controls mentioned.

Report back on how the application holds up.

HTH
--
Rob

FMS Professional Solutions Group
http://www.fmsinc.com/consulting

Software Tools for .NET, SQL Server, Visual Basic & Access
http://www.fmsinc.com

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Hi,
I'm have a serious issue with a database I'm developing for a customer who

is anxious for it to be completed. The problem...well, the symptom of the
problem, is very clear. When I run the compiler in the VBA window, the
compiler progress bar gets about 3/4 through compiling, then Access
completely crashes. I've had the problem on 2 different machines (on the
same MDB file under development).

I'm really stuck. I don't have a clue. I'm not sure if exporting all

objects from the MDB file into a new, blank database might help. I've been
building Access and SQL Server databases for years, but this is a real nasty
problem. I thought it might just be the machine until I tried it on another
and had the same problem. I can't open a support incident with Microsoft
because it costs too much money (WAY too much).

Here's the specifics: I'm running Access XP, SP3. The machines I've

experienced the crashes on are Windows XP Pro and Windows 2000 Pro. I'm not
using any 3rd party objects or libraries in the project. The database is
split into front and back end. About the most "extravagant" objects in the
design are a couple of forms that have Excel spreadsheets embedded in them.
I'm using other Microsoft objects like Date Time Picker controls and
Progress Bars.

 

[Bill Taylor]

I would try commenting out blocks of code ( like 50% at a time) to isolate
the offensive code. Dont know if this will solve your problem but it is what
I would try first before a Colt 45.

Hi,
I'm have a serious issue with a database I'm developing for a customer who

is anxious for it to be completed. The problem...well, the symptom of the
problem, is very clear. When I run the compiler in the VBA window, the
compiler progress bar gets about 3/4 through compiling, then Access
completely crashes. I've had the problem on 2 different machines (on the
same MDB file under development).

I'm really stuck. I don't have a clue. I'm not sure if exporting all

objects from the MDB file into a new, blank database might help. I've been
building Access and SQL Server databases for years, but this is a real nasty
problem. I thought it might just be the machine until I tried it on another
and had the same problem. I can't open a support incident with Microsoft
because it costs too much money (WAY too much).

Here's the specifics: I'm running Access XP, SP3. The machines I've

experienced the crashes on are Windows XP Pro and Windows 2000 Pro. I'm not
using any 3rd party objects or libraries in the project. The database is
split into front and back end. About the most "extravagant" objects in the
design are a couple of forms that have Excel spreadsheets embedded in them.
I'm using other Microsoft objects like Date Time Picker controls and
Progress Bars.

 

[Guest]

Rob

After posting my message, I continued trying to track the problem. I ended up doing part of what you said; I imported ALL objects (including the embedded spreadsheet, DTPicker, and PBars). The compile finally worked. No errors reported. One thing I noticed was that the file size of the "new" front end MDB file was significantly less; the original was about 62 MB, the new one about 48 MB. After every design session, and sometimes during, I always compact/repair so it wasn't that I hadn't been compacting. I've been testing the general operations of the program and they seem to be OK. I triple-checked to make sure I had imported all objects, which I had.

Now I'm wondering if there's some benefit to occasionally importing a project into a blank database, especially if it's one that's been under continuing development and modification

Thanks for your help
Paul

 

[Guest]

Bill

After trying the Colt 45 with no observable improvement, I continued trying to solve the issue. I imported all objects into a new, blank database, but I did the forms in small groups. After doing each group of forms, I ran the compiler to see if I could find a suspicious form(s), but to no result. When I got everything in, the "new" MDB file compiled fine without errors. The compile finally worked. No errors reported. One thing I noticed was that the file size of the "new" front end MDB file was significantly less; the original was about 62 MB, the new one about 48 MB. However, after every design session, and sometimes during, I always compact/repair so it wasn't that I hadn't been compacting. I've been testing the general operations of the program and they seem to be OK. I triple-checked to make sure I had imported all objects, which I had.

I went a step further on another project that has a much bigger front end MDB file, about 110 MB (no embmedded graphics, just Access objects). The new MDB file was reduced to a paltry 65 MB. Is there some benefit to occasionally importing a project into a blank database, especially if it's one that's been under continuing development and modification? If there's even a small improvement in performance it seems like it might be a good thing. But 2 big questions remain: 1) What caused the crashes in the first place, and B) What was taking up the extra space in the MDB file before it got imported into the blank file

Although I've been building databases for a long time and got a masters in it, I don't think a day goes by that I don't stop for a minute, amazed at how much I've learned, but more importantly, how much I still need to learn

Regards
PaulJS

 

[John Spencer (MVP)]

Importing cleans up some things that compacting does not.

One of the things is artifacts of old code. -- You've changed the code and
saved it. This sometimes leaves behind "junk" - old code you've deleted.

Another method that gets rid of the "junk" is to use the decompile switch.
Undocumented feature, look it up in the groups in google.

I know several developers that as a matter of course, always import into a new
database just before delivery. It does eliminate a lot of potential problems,
but it can also cause you a problem if you are not careful and make sure you
have all your settings, etc handled after the import into a new db.

 

[RobFMS]

There are a variety of things that can cause an Access database to bloat in
size.
Some include:
- Embedding images
- Memo fields

I know there are a few Acces sites that discuss this more in detail.

--
Rob

FMS Professional Solutions Group
http://www.fmsinc.com/consulting

Software Tools for .NET, SQL Server, Visual Basic & Access
http://www.fmsinc.com

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Rob:

After posting my message, I continued trying to track the problem. I

ended up doing part of what you said; I imported ALL objects (including the
embedded spreadsheet, DTPicker, and PBars). The compile finally worked. No
errors reported. One thing I noticed was that the file size of the "new"
front end MDB file was significantly less; the original was about 62 MB, the
new one about 48 MB. After every design session, and sometimes during, I
always compact/repair so it wasn't that I hadn't been compacting. I've been
testing the general operations of the program and they seem to be OK. I
triple-checked to make sure I had imported all objects, which I had.

Now I'm wondering if there's some benefit to occasionally importing a

project into a blank database, especially if it's one that's been under
continuing development and modification?