Why is saving a file so slow?

[jglassner]

Aloha

I split my database and overall I am happy. My one issue is when I save the file it takes forever when I am on the VPN network,. I understand that a VPN will be slower but I thought that splitting the database would speed that up as I am saving a local file. What could be making it slow down? A simple save can take a few minutes.

Thanks,
Jason

 

[Joe4]

Are you running regular Compact & Repair on your databases to keep them as "lean" as possible?

 

[jglassner]

I do with every close. I think I am confused as to why saving the front end takes so long? I assumed the local file would save quickly, does the FE access the back end when it closes. Can that be changed or should it be?

 

[Joe4]

I do with every close. I think I am confused as to why saving the front end takes so long? I assumed the local file would save quickly, does the FE access the back end when it closes. Can that be changed or should it be?

How many people are using the database?
Does each person have their own copy of the front-end?

If you have the front-end dataabase running a Compact/Repair evert time it closes, that could be part of the problem. You really shouldn't "Compact/Repair" on every close. I believe it can even cause corruption if you have multiple people attempting to compact the back-end at the same time. Typically, the back-end should be Compacted and Repaired right from the placed it is located on the Network (and note remotely via VPN). You might schedule a job to do it off hours.

There shouldn't be a huge need to Compact/Repair the front-end that often, as it shouldn't contain any data, only the queries, forms, reports, and VBA code. So people shouldn't be adding much to it. Compacting it before distributing new copies of the front-end (when changes are made) may even be sufficient.

 

[jglassner]

Yes, each person has their own FE, but that shouldn't be the issue. A simple update to a form or report takes minutes to save and it is a local file, not saving over a network. A local file should save quickly, it seems that at close Access is doing something with the BE I just don't understand what it would be.

 

[Joe4]

You said that your run a Compact & Repair "with every close".
Where exactly does that happen? Is that on thr front-end?
If you temporarily disable it, and try again, does that improve the speed?

 

[Micron]

I would not c&r on every close and would suggest saving a backup before doing so, assuming backups are not routine anyway.
There is no "save" to an Access file unless you're talking about design changes, and that should only be on the fe. If you mean a record save, that is a different matter. If you're talking about opening and closing forms/reports and all of them are super slow, then try opening an editable queyry directly and making one small change to any non-indexed field (e.g. add a period to a text field but remove it upon successful edit). If you make this edit and move off of the record and it chugs forever, then I don't know, except to say that I don't see how you can start a vpn session on your local machine and imply that because the db is local on that machine, you're not running through the vpn. Accessing any records would automatically be channeled through the vpn if the be is remote. Then again, vpn's are not my forte. I think you might have the wrong impression about "saving" data in Access. It is not like Word, where any changes to text need to be manually saved.