Some advice please :(

[Ferenc]

I am new to access, only started to use it for a project recently.
I do the development using a remote PC using remote desktop connection. The problem I am facing is every now and then when I try to load the database it comes up with an error message saying the database is corrupted, sometimes it says it is due to an interrupted network connection, sometimes it comes up with an error message stating the VBA code is corrupt etc.
It means usually I lose that instance of the entire file, sometimes I lose only the VBA code (strangely everything else remains intact). If someone could explain why is this happening and what could I do to avoid it (apart from creating a backup copy in every 15 mins). Is this a common issue with access?

 

[CJ_London]

is your database split? If not, this could be the cause of your problem.

If you are using remote desktop then every thing is run on that remote machine, the only thing transferred across the web is updates to the screen image. So lost connections should not affect it.

If you are trying to copy a db from the remote machine to your own machine, an interruption in the connection could cause a problem - suggest you zip before transferring

 

[Ferenc]

Everything is on that remote PC.

 

[CJ_London]

if everything is on the remote pc (frontend and backend) then I don't see how you are getting an interrupted network connection.

Suggest you compact the backend and decompile and compact the front end

 

[marlan]

Hi,
Yes, corruption is an issue in access...!
I have recently lost a few VBA Modules to corruption... I was testing data for a client, and thought it was a short term job, I was working on my lap-top (no network!), and haven't split 200MB of data from FE...
I had to recreate some nice amount of VBA code.

see this on preventing corruption: http://allenbrowne.com/ser-25.html
see this on recoverrng from corruption: http://allenbrowne.com/ser-47.html

ATB!

 

[gemma-the-husky]

I would

a) split the data
b) develop against a separate copy of the front end
c) make frequent backup copies of the front end
d) version the front end regularly, to minimise any possible development loss.
v1.00
c1.00a
v1.00b
v1.00c
v1.01
etc