Brian Scanlon <BrianScanlon[ at ]discussions.microsoft.com> wrote in news:616B5663-4CBC-4A19-B0A5-4BDE8A1120A1[ at ]microsoft.com:
[Quoted Text] > "David W. Fenton" wrote: > >> Brian Scanlon <BrianScanlon[ at ]discussions.microsoft.com> wrote in >> news:C29AB1CD-9DEA-413B-A562-CD86D1525F27[ at ]microsoft.com: >> >> > We have a problem where replicas in our replica set will >> > start blowing up >> > to 2GB. We do a compact/repair and they go down to their >> > normal 200-300MB and then as they are used they are used and >> > replicated they start growing again. We fight with this for a >> > while rebuilding replicas and compacting and are able to make >> > the problem eventually go away and then it comes back. We are >> > doing indirect replication with replication manager 4.0. >> >> Are you using a split architecture (data tables replicated, >> forms/reports/etc. not replicated)? > NA, the app is written in staright VB not Access VBA > >> Are you adding and deleting a lot of records? > Yes
Then that's the source of your problem. Replicated databases should not have lots of deletions.
If you need temporary records, *don't* do them in the replicated tables, but in a non-replicated table, preferably in a temp MDB that you can recreate at will without ever having to .
>> Are you editing querydefs in DAO in your replicated MDB? > No > >> Any of these things can cause unnecessary bloat. >> >> All of them are problematic with replicataion. > > Yes we know that we are probably psuhing Access replication to > its limit. We hope to eventually switch to an SQL server, but we > don't have the time to do that right now (and I am not sure when > we will with all the time we spend trying to keep replication > running)
Large numbers of deletions are a huge mistake in a replicated app.
I made the mistake in my first replicated app, but I've never made it again.
Remember: don't add any data to your replica that you don't want propagated to the other replicas. If there are "scratch" records used temporarily, then there is no justification for adding them to a replicated table in the first place.
-- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
|