VBA Project Deleted

[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 Bass via AccessMonster.com]

Hi Debbie,

The most likely cause is corruption, perhaps do to all the changes;
network or computer failures or who knows what.

Do you do compact-and-repair? How about doing a decompile/recompile
before providing the files to your users? See <
http://www.granite.ab.ca/access/decompile.htm> for details. It would not
hurt to create a totally new database and import all of the current FE's
contents into it after doing a decompile, but not a recompile. Then you will
have a very fresh version of the database.

Are you having the users run the FE from their local computers or the
network? If the network, make the shift to locally. Using an FE on the
network can be problematic. See <http://autofeupdater.com/> for one option
to pushing out updates to the FE to the clients. If you are already doing
that, and the network speeds do not make it a nusiance, a further option
might be to provide a new copy of the FE to the user each time they run it.
Or a slight variant, to keep an update-to-date copy on their local machine
and always make a copy from it when they run the program; then open the copy
instead of the original. I am not sure if Tony Toews's Auto FE Updater
provides the option for the user to manually refresh their copy in the event
of corruption. If so, that could be another option.

Hope that helps,

Clifford Bass

 

[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 Bass via AccessMonster.com]

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,

[quoted text clipped - 52 lines]

 

[Debbie]

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

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,

[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

--



.

 

[Clifford Bass via AccessMonster.com]

You are welcome Debbie. And good luck with that.

Clifford Bass