I've just successfully spitted a DB of 30+ MB of size to front end and back end.
However the size of front end is roughly the original one and the size of back end is some KBs. Shouldn't have been the exact opposite considering that data are stored to the back end?

I've just successfully spitted a DB of 30+ MB of size to front end and back end.
However the size of front end is roughly the original one and the size of back end is some KBs. Shouldn't have been the exact opposite considering that data are stored to the back end?

Data actually doesn't take up as much room as forms, reports, queries, macros, and modules.

Data actually doesn't take up as much room as forms, reports, queries, macros, and modules.

Maybe you are right I don't know much about this,
but what makes me believe that 30MB comes from data
is the comparison between the clean DB (~5MB) and the DB after filling in the data (~30MB).

just splitting the front end may not reduce the size - have you tried compacting it - also images tend to bload a database, if there are any

but 20-30mb is not too big anyway for a substantial dbs - the size shouldnt realy be an issue

just splitting the front end may not reduce the size - have you tried compacting it - also images tend to bload a database, if there are any

but 20-30mb is not too big anyway for a substantial dbs - the size shouldnt realy be an issue

Reducing the size is not my purpose right now.
I'm just experimenting on DB splitting and I assumed that a result
of a greater front end shows that something went wrong.

This is normal. When you delete from a db about the only change in size you will see is from nothing to an increase.

Access appears to keep (somewhere??) whatever is deleted and can generate some "extra" just with the delete process. Compacting removes "the fat"

Data actually doesn't take up as much room as forms, reports, queries, macros, and modules.

Have to disagree with you there Bob.

An example, I just imported a large table from my db into a blank db and then compacted.......10.9mb

Imported table from db into another blank db, deleted all records from table and compacted....288kb

Then deleted the table from the db that had data in the table and size went from 10.9mb to 11 mb. Compacted and size dropped to 120kb

Have to disagree with you there Bob.

An example, I just imported a large table from my db into a blank db and then compacted.......10.9mb

Imported table from db into another blank db, deleted all records from table and compacted....288kb

Then deleted the table from the db that had data in the table and size went from 10.9mb to 11 mb. Compacted and size dropped to 120kb

It all depends on what you've got in the db.

It all depends on what you've got in the db.

Obviously if you have lots of forms and little data the data will be the small part.

But I would imagine that most "working data bases" would have most of the megabytes in the data.

Obviously if you have lots of forms and little data the data will be the small part.

But I would imagine that most "working data bases" would have most of the megabytes in the data.

Not in the front end of a split database...

Not in the front end of a split database...

But isn't that what we are saying. The font end has no data and so if the data is a large part then after compacting the front end will be smaller, much smaller in many cases than the back end.

I think we are mixing up a bit of terminolgy or perhaps the way it is done.

In my case I leave all the forms, queries etc in the "home data base" whereas I suspect you talking about the "home/backend" only having tables

The backend should ONLY have tables or queries, it should NOT have other objects - no forms, reports, macros, or code. If it does it greatly increases the liklihood of corruption and if users are using the same objects then it defeats the purpose of the split database to begin with.

http://members.shaw.ca/AlbertKallal/Articles/split/index.htm

Anyway, the front end, after compacting may or may not be smaller than then backend with data. If you have any forms with embedded images, it will be much larger than the data for quite a while until you get enough data in the database.

I never knew it could cause corruption problems.

We do use the "home data base" at the same time. In fact it is the one I use. Also use it for some slow running stuff that is done first thing in the morning and at end of day.

From what I have read on the forum my other potential corrupter (is that a word??:)) is my network is over a combination of cable and wireless.