What is considered a large database? Right now mine is 3M and we hope to add a lot more features and I'm worried about the size. I know if you convert it to *.mde it will be small and load faster, but b/c you are prevented from doing design changes I'm kind of edgy about that. I would like my users to use the *.mde file to enter their own data, but I what if I occasionally need to make changes, then the *.mdb version of my database will be out of date. Any suggestions, what's the best way to go about this?
size (1 Viewer)
- Thread starter skate
- Start date
ghudson
Registered User.
- Local time
- Today, 08:24
- Joined
- Jun 8, 2002
- Messages
- 6,194
A three meg db is small potatoes. That size db will easily zip up and fit on a diskette. We have db's that are over half a gig and some that are close to a gig in size. Some functions are slow (DLookup) but tolerable considering the db's are on a network
I do NOT recommend converting your db's to MDE. To many hassles when you need to make changes to the db's. A MDE will be smaller in size but not that much of a difference. The code might run faster but I can not say I see a difference.
HTH
I do NOT recommend converting your db's to MDE. To many hassles when you need to make changes to the db's. A MDE will be smaller in size but not that much of a difference. The code might run faster but I can not say I see a difference.
HTH
- Local time
- Today, 08:24
- Joined
- Feb 19, 2002
- Messages
- 43,626
A2K has a "feature" that causes numerous problems including slow loading. Open Tools/Options and uncheck all the track name changes options. Close and compact the db. If you will be making changes that you want to have Access help you with, turn the track name changes options back on, make the changes, and then turn them off again.
Splitting the tables into a separate db will make future maintenance easier for you. You can then convert the front end db to an .mde (don't forget to save the .mdb version in a SAFE place or you will be up the creek without the proverbial paddle). The .mde file links to the tables in the back-end db. You can then make changes to your .mdb version, recreate the .mde and simply overlay the client copy of the .mde without affecting their data. Of course if you need to make table changes, you will need to modify the back-end db but you would have had to do that anyway.
Splitting the tables into a separate db will make future maintenance easier for you. You can then convert the front end db to an .mde (don't forget to save the .mdb version in a SAFE place or you will be up the creek without the proverbial paddle). The .mde file links to the tables in the back-end db. You can then make changes to your .mdb version, recreate the .mde and simply overlay the client copy of the .mde without affecting their data. Of course if you need to make table changes, you will need to modify the back-end db but you would have had to do that anyway.
Autoeng
Why me?
- Local time
- Today, 08:24
- Joined
- Aug 13, 2002
- Messages
- 1,302
Tips to spped up your database
A great article on db speed with 168 tips to improve it can be found on www.fmsinc.com/tpapers/faster/. The article covers EVERYTHING including server settings, db design, VB code, EVERYTHING! Give it a look.
Autoeng
A great article on db speed with 168 tips to improve it can be found on www.fmsinc.com/tpapers/faster/. The article covers EVERYTHING including server settings, db design, VB code, EVERYTHING! Give it a look.
Autoeng
Last edited: