VBA Project Deleted

  • Thread starter Thread starter Debbie
  • Start date Start date
D

Debbie

Hello,
I'm experiencing something with A2007 that I have never seen before. All
the code in my forms/reports/modules was simply gone! I know a user did not
delete anything. When I tried to open a module I had written, I got the
following message:

The database cannot be opened because the VBA project contained in it cannot
be read. The database can be opened only if the VBA project is first deleted.
Deleting the VBA project removes all code from modules, forms and reports.
You should back up your database before attempting to open the database and
delete the VBA project.

I have gotten this message on two other occassions at different
installations. All databases are split with FE/BE configuration. All are
running Windows XP. All users have the same level of Access and XP. All are
on a network, I have one customer who has Access installed on the clients and
one coming in through Terminal Services.

I have compliled this code everytime I make a change and it compiles without
errors. I cannot imagine what is doing this. Does anyone have any ideas? I
have researched it for the past hour and though lots of people have had this
happen, no on really seems to know what causes it. I've even read that
McAfee has been known to do this. I fear this will keep happening and
although we have backups, which I had to use, it is a real pain and I fear
the clients will view Access and unstable.

Does anyone have any idea of why this is happening and how I can avoid it in
the future? Thank you so much, Debbie
 
Clifford,
Thank you so much for your reply. To answer your questions:
-Yes, we do do a compact and repair but not automatically when the db
closes. Perhaps I should do that on both front end and back end?
-I always compile but I have not decompiled. Just to clarify your
suggestion; I should decompile the current database and then import the
objects in the new database? Should I then recompile the new database?
-Because we are using Terminal Services, both the FE and BE are on the
server. We chose to do it that way because of maintaining the front end.
The locations that use this are all over northern NJ and it would be a huge
pain to update all of them. I did know that it's best to put the FE on the
local machines but it's not practical here. Thankfully we have an excellent
back up system! Your other suggestion about making a copy and then running
that may be an option for us.

Thanks again, you've been very helpful.
Debbie
 
Clifford,
Thank you SO MUCH, you're advice has been helpful and I will investigate
your suggestions.
Take care,
Debbie

Clifford Bass via AccessMonster.com said:
Hi Debbie,

Multiple users of the same FE is known to be a cause of corruption. A
scheduled compact and repair of the BE is a good idea, and cannot hurt (as
long as you have a backup before doing it). Maybe once a week? I would not
set the BE to do auto-compacting. It can cause a significant delay for the
final user closing out his/her FE.

I would suggest focusing primarily on the FE. Certainly it may help to
set them to auto-compact when closed. I did not do it in the past, but I
have been shifting in that direction myself. For a terminal server type
situation, you can still set it up so that each user uses his/her own copy of
the FE. Probably though the use of a home directory for each individual; a
logon script or somesuch method. I am not expert in that area. If you
likewise are not, your IT coworkers should be able to help. I believe Tony's
Auto FE Updater is designed to work in a terminal server situation also.

About the decompile / import. Do do the decompile/recompile of each new
version of the FE before providing it to your users. Usually you do not need
to do the import into a new database unless you are encountering problems.
Since right now you state that you are occasionally encountering problems,
doing so now would be wise. But then you don't really need to worry about it
until more issues come up. Things accumulate in a database over time that
even a compact and repair do not totally get rid of. Doing the decompile
before the import I am thinking will help prevent carryover of any issues
related to compiled code because you will only be copying the actual text of
the code instead of both the text and the compiled code. (I might be totally
wrong about that so if someone else knows different, feel free inform us.)
Yes, once in the new database you will need to recompile. You will also need
to make sure all your references are set accordingly (VB Editor, Tools menu,
References... item).

Hope that is helpful,

Clifford Bass
Clifford,
Thank you so much for your reply. To answer your questions:
-Yes, we do do a compact and repair but not automatically when the db
closes. Perhaps I should do that on both front end and back end?
-I always compile but I have not decompiled. Just to clarify your
suggestion; I should decompile the current database and then import the
objects in the new database? Should I then recompile the new database?
-Because we are using Terminal Services, both the FE and BE are on the
server. We chose to do it that way because of maintaining the front end.
The locations that use this are all over northern NJ and it would be a huge
pain to update all of them. I did know that it's best to put the FE on the
local machines but it's not practical here. Thankfully we have an excellent
back up system! Your other suggestion about making a copy and then running
that may be an option for us.

Thanks again, you've been very helpful.
Debbie
Hi Debbie,
Click to expand...
[quoted text clipped - 52 lines]
Does anyone have any idea of why this is happening and how I can avoid it in
the future? Thank you so much, Debbie
Click to expand...
Click to expand...

--
Message posted via AccessMonster.com


.
Click to expand...
 
Back
Top