FE size is same as before split.

[Guest]

I split my database recently using the database splitter without issue. I
use a batch file to load the FE onto the users computer and keep both FE and
BE on a shared drive.
After the split though I noticed the FE is still the same size 16 meg, and
the BE is around 11 meg.
When I back-up the FE though the back-up copy is only 4 meg.
It seems the FE still contains the tables but it shows them as linked tables
now.
My question is am I suposed to delete the table(links) in the FE. I assumed
that they were just representing links and not actually the tables themselves.

 

[Dirk Goldgar]

I split my database recently using the database splitter without
issue. I use a batch file to load the FE onto the users computer and
keep both FE and BE on a shared drive.
After the split though I noticed the FE is still the same size 16
meg, and the BE is around 11 meg.
When I back-up the FE though the back-up copy is only 4 meg.
It seems the FE still contains the tables but it shows them as linked
tables now.
My question is am I suposed to delete the table(links) in the FE. I
assumed that they were just representing links and not actually the
tables themselves.

You must not delete the linked tables in the FE. Did you compact the
front-end after the split? You need to do that to regain the unused
space.

 

[Guest]

Do a compact and repair. Or better yet, don't worry - be happy. 16 mb is a
drop in the bucket compared to the 2 GB file mdb file size limit.

 

[Guest]

The compact and repair did the trick. Thanks Dirk and Jerry.
and the 16 meg is just the start. I expect it to grow quickly 10 times that.
btw, is the 2gig limit for FE, BE, or both.
I don't expect the FE to grow anymore, but the BE... well, that's a
different story

 

[Dirk Goldgar]

The compact and repair did the trick. Thanks Dirk and Jerry.
and the 16 meg is just the start. I expect it to grow quickly 10
times that. btw, is the 2gig limit for FE, BE, or both.
I don't expect the FE to grow anymore, but the BE... well, that's a
different story

The 2GB limit is for each individual .mdb file, so the BE is likely to
be the limiting factor. You'll probably start to run into problems
before you hit 2GB, though, as Access needs to get temporary space in
the file for various operations.

It's unusual, though not unheard of, to have an application that is
suitable for Access in other ways, that really uses a back-end bigger
than 2GB. Usually, other considerations mandate using a server database
such as SQL Server for the back-end, before you hit the 2GB limit.
However, if you have to, you can use multiple Jet back-ends for the same
front-end, each back-end providing up to 2GB of storage.

 

[Joseph Meehan]

The 2GB limit is for each individual .mdb file, so the BE is likely to
be the limiting factor. You'll probably start to run into problems
before you hit 2GB, though, as Access needs to get temporary space in
the file for various operations.

It's unusual, though not unheard of, to have an application that is
suitable for Access in other ways, that really uses a back-end bigger
than 2GB. Usually, other considerations mandate using a server
database such as SQL Server for the back-end, before you hit the 2GB
limit. However, if you have to, you can use multiple Jet back-ends
for the same front-end, each back-end providing up to 2GB of storage.

To add to Dirks answer, often when someone has a database that
approaches that size, it may well be a poorly normalized database and
wasting a lot of space, slowing down the process as well.

Also if the data is often edited or some of it deleted, you may want to
establish some protocol to compact and repair the database on a regular
schedule.