Pa verovatno klijenti puno brisu(pisu), u raznim formatima baza podataka imas opciju "ciscenja" slogova, kao npr. vaacum u postgre ili "pakovanja" u paradox. Posto ne poznajem verziju koju si pomenuo, pokusaj da nadjes u okviru biblioteke alat(dll) koji mozes da pozoves prilikom brisanja, a koji moze da ti resi problem pakovanja praznih zapisa. Verovatno bi bilo dobro da iskoristis dogadjaj snimanja za "ciscenje" praznih slogova ili da bolje edukujes korisnike.

Postoje par uslova pod kojima veličina baze može brzo da se povećava. Ja ću ovde da navedem ukratko, a ti probaj da potražiš više detalja o svakoj opciji.

1. Transaction log - ako imaš puno transakcija koje se startuju u kratkom vremenskom periodu; ako transakcije dugo traju, ako se u okviru jedne transakcije menja velika količina podataka (ponu INSERT, UPDATE i DELETE komandu u okviru jedne transakcije).
2. Loše dizajnirana baza - ovde puno različitih poduslova može da ima uticaja. Jedan od bitnijih je PAGE SIZE za bazu. Takođe, ako imaš BLOB kolone sa velikom količinom podataka.
3. Garbage collector - Mehanizam koji vodi računa o iskorišćenosti "slobodnog prostora" unutar baze. Ako se često koristi INSERT/DELETE, pod određenim uslovima može da dođe do nagomilavanja podataka u bazi jer GC ne stiže da uradi svoj posao. GC je takođe u sprezi sa Transaction logom.

Ja najviše sumnjam na rad sa transakcijama. Postoji mogućnost da imaš nezatvorene transakcije ili "limbo" transakcije. Pogledaj malo o tome na netu. Siguran sam da ćeš naći dovoljno informacija.

Da li možeš da nam kažeš kako se pristupa bazi, tj. u čemu je rađena klijentska aplikacija i da li imaš mogućnost da menjaš tu aplikaciju?

Klijentska app je rađena u D2007, naša.
Program je knjigovodstveni i kod ostalih stranaka je OK, ne dolazi do naglog rasta baze.

Backup/restore uredi veličinu baze, znaći da je vjerojatno problem u brisanje/mjenjanje/upis i starim verzijama slogova.