Project Access 64bit vs 32bit, file dimension very different (4 Viewers)

[amorosik]

I have a project created with Access 2024, the 64-bit version
All the API declarations are in the 32/64-bit version, so I can transfer the exact same project to another PC with Microsoft Access 2013, the 32-bit version, installed
I periodically use the Tools/Compact and Repair Database function to reduce the size of the Access file
I noticed that if I transfer the file from a PC with 64-bit Access to a PC with 32-bit Access, and then run Tools/Compact and Repair Database on the latter, the size is significantly reduced, from 110 MB to about 70 MB (only code, no db data)
I'm talking about the .accdb file

The question is: since the difference seems significant (in a 32-bit environment the program is about 30% smaller), I'd like to know if you think this is justified or if it's due to some anomaly

 

[tvanstiphout]

Do you also use /decompile? I would definitely do that if minimum size is your goal.
I would assume the compiled state in 64-bit is a bit larger (maybe 20% or so) than the 32-bit one.

 

[CJ_London]

Do you compact/repair just before you transfer? Compacting ‘periodically’ implies not. And does your file contain tables? Or just linked tables?

 

[unmateria]

U need to make a /decompile... is not the same as compact/repair by faaaaaaaaar if u want to reduce size

 

[The_Doc_Man]

That change - 110 MB to 70 MB - is about 63%, which is far bigger than I would have guessed. The part that makes this really difficult to answer is that Access is not OpenSource so we can't tell how many LongPtr (64-bit) types are converted when you compile. However, I noticed that the two DBs, at least as you initially described it, are different versions - 2024 for 64-bit, 2013 for 32-bit - and the libraries significantly changed between those two versions. But then again, if neither version is actually open at the time, then the libraries aren't resident at that time either. When testing the sizes, has either the 64-bit version or the 32-bit version been opened and then closed again? I would believe that the first time each one was opened, there is at least a chance of a forced recompile.

It is an interesting question, amorosik, but without proper tools to look at the program sections for the .ACCDB front-ends, I don't know how to analyze that.

 

[amorosik]

Do you compact/repair just before you transfer? Compacting ‘periodically’ implies not. And does your file contain tables? Or just linked tables?

Only linked table

 

[amorosik]

Do you also use /decompile? I would definitely do that if minimum size is your goal.
I would assume the compiled state in 64-bit is a bit larger (maybe 20% or so) than the 32-bit one.

No, /decompile is not used

 

[amorosik]

...I noticed that the two DBs, at least as you initially described it, are different versions - 2024 for 64-bit, 2013 for 32-bit - and the libraries significantly changed between those two versions....

Yes this may be part of the issue

... When testing the sizes, has either the 64-bit version or the 32-bit version been opened and then closed again? I would believe that the first time each one was opened, there is at least a chance of a forced recompile.

Yes, I tried opening and closing it, but the size didn't change significantly.To see if something was missed in the transition, I also tried debugging/compiling, and it worked fine.

It is an interesting question, amorosik, but without proper tools to look at the program sections for the .ACCDB front-ends, I don't know how to analyze that.

What you mean for "..proper tools.." ?