Size of the database does not change

[valeryk2000]

I save copies of my .mdb file daily for a month in a special folder. Database is actively used. Users add new records, queries. However the size of the database in Windows Explorer remains the same. Compact/repair does not change the size. I attach a snapshot of the folder ...
Never heard of anything like that.

 

[theDBguy]

Is your database split?

 

[valeryk2000]

Is your database split?

No.

 

[theDBguy]

No.

Everybody is using the one and the same mdb file on a network folder?

 

[valeryk2000]

Everybody is using the one and the same mdb file on a network folder?

Just one Access mdb file. Several users may use it simultaneously. Note: the file is used about 10 years without serious problems. Just lately the corporate laptops (~1600) were upgraded from Win 7 to Win 10, and Office 10 to Office 365.

 

[The_Doc_Man]

Is it feasible for you to look into the various database to see if their content and the dates on the file are consistent? (I.e. maybe you are saving the wrong file?) I would have bet a pizza that such a situation as you describe is not possible in a monolithic database that actually does something.

 

[valeryk2000]

Is it feasible for you to look into the various database to see if their content and the dates on the file are consistent? (I.e. maybe you are saving the wrong file?) I would have bet a pizza that such a situation as you describe is not possible in a monolithic database that actually does something.

I checked the database tables: the number of records grow ... I thought may be this is something wrong with win explorer and checked properties of the copies - no, that's right, all copies have the same Size and Size on the disk ... and I would add to your pizza bet a case of beer that it's not possible ... but ...

 

[gemma-the-husky]

Have you ever done a compact and repair? Maybe there's a lot of spare space waiting to be reclaimed, and the database is just writing into the reclaimed areas gradually, so it never gets smaller, rather than bigger. 123Mb indicates there should be a fair amount of data in the database.

I mean it won't get smaller without a C&R, but it might not get bigger either in the circumstances above.

 

[Gasman]

Just one Access mdb file. Several users may use it simultaneously. Note: the file is used about 10 years without serious problems. Just lately the corporate laptops (~1600) were upgraded from Win 7 to Win 10, and Office 10 to Office 365.

I'd be buying a lottery ticket about now.

 

[valeryk2000]

Have you ever done a compact and repair? Maybe there's a lot of spare space waiting to be reclaimed, and the database is just writing into the reclaimed areas gradually, so it never gets smaller, rather than bigger. 123Mb indicates there should be a fair amount of data in the database.

I mean it won't get smaller without a C&R, but it might not get bigger either in the circumstances above.

C&R does not change anything ...

 

[valeryk2000]

C&R does not change anything ...

I forgot to mention that the size froze after the database was corrupted and restored from the nightly share drive backup ... is it possible that the "corruption" did something with the database ability to "report" on its size?

 

[isladogs]

Just one Access mdb file. Several users may use it simultaneously. Note: the file is used about 10 years without serious problems.

I forgot to mention that the size froze after the database was corrupted and restored from the nightly share drive backup

As you didn't respond to Gasman's earlier reply, your setup is a disaster waiting to happen.
Letting users share the same db simultaneously is a recipe for disaster. Corruption is inevitable. Restoring from a backup isn't a satisfactory solution
The db size is the least of your problems.
As a priority, split the db, put the BE on the network and give each user their own copy of the FE on their own workstation

 

[valeryk2000]

As you didn't respond to Gasman's earlier reply, your setup is a disaster waiting to happen.
Letting users share the same db simultaneously is a recipe for disaster. Corruption is inevitable. Restoring from a backup isn't a satisfactory solution
The db size is the least of your problems.
As a priority, split the db, put the BE on the network and give each user their own copy of the FE on their own workstation

Actually I want to move tables and some codes to SQL Server and to use mdb only as a front end ... But the "size" phenomenon (some swear words) ...

 

[valeryk2000]

As you didn't respond to Gasman's earlier reply, your setup is a disaster waiting to happen.
Letting users share the same db simultaneously is a recipe for disaster. Corruption is inevitable. Restoring from a backup isn't a satisfactory solution
The db size is the least of your problems.
As a priority, split the db, put the BE on the network and give each user their own copy of the FE on their own workstation

As you didn't respond to Gasman's earlier reply <== you mean I did not buy a lottery ticket?

 

[isladogs]

Ha! No you didn't appear to respond to it!

Moving to SQL Server will take time. By then you could have unrecoverable corruption. You need to split the database immediately!

 

[jdraw]

I agree with others in that you seem to have been extremely lucky having avoided corruption for a long time. Are you certain that the database is still operational?

 

[valeryk2000]

I agree with others in that you seem to have been extremely lucky having avoided corruption for a long time. Are you certain that the database is still operational?

 

[valeryk2000]

Spiting is a way to go (I tried it with other databases some time ago, FE linked to BE - it slows down the performance to the degree of users loosing not only patience but sanity).

 

[isladogs]

Slow performance is fixable. Corruption may not be.

 

[valeryk2000]

Slow performance is fixable. Corruption may not be.

This is very true ... but (back to our sheep) why the size is the same?