Would creating a front-end, back-end scenario be any better?
Would the temp data be computed on the front-end and only the results
stored to the back-end?
Any advise would be appreciated.
-Joe
No, a split database will not really help. However, creating temp mdb for
some data manipulation, and then throwing it away can certainly help.
I assume that if you start with a fresh compacted database, and import you
wind up with about 400 megs. The next question would be what kind of data
manipulation are you doing to the data?
Often, a few simply changes in how you modify the data can make dramatic
reductions in the file "growth" size. For example, you might be modifying
only one field. If you add data to that field, then the whole record can not
"fit" were it currently is located, so ms-access makes a copy of that record
to the new spot. If on the other hand, during importing you can pad that
field, and then when you run your code to "modify" that field, the record
can still fit in its current location..and volia..no bloating of the file
after you process your data.
It really comes down to avoiding deleting records (which don't recover used
space until you compact), avoiding temp tables (unless you place them
outside in a linked mdb that you throw away when done), and also avoid
expanding record sizes beyond what current space they take up...
So, there is a number of "general" development and programming practices
that we can, and do adopt to reduce this bloat problem....
