Each one of these rules deserves its own 10 minute video. And worthy of argument on the nuances. Each developer encounters their own unique challenges which may require variations on these rules but these are a very good start.
Agreed, I could easily expand on most, but I was trying to make a smaller, more easily digestible overview video. Sometimes less is more. I'm hoping this was one of those cases.
Nice compilation, most of which i knew and follow follow. The one about one subform to hold a graphic was new to me. I was amused by how many consist of turning off various conveniences that access provides.
Thanks for supplying the attachment method database as a download, this saves me a ton of time trying to workout it out for myself the way that it is demonstrated in the db download (method 2)
I agree with you 100% of your advices. I also use a couple of features (with no issues) that you don't talk about: 1) Calculated fields on tables 2) Data macros Many access developers claim that they don't have to be used, but I dissagree with them.
I avoid both. In the right hands they are fine, but I still like to do calculations in queries and data changes and trigger them myself. There also the issue of upsizing to other RDMS with such feature implemented. But many use them and love them.
Thanks Daniel, I learned something new today. I was not previously aware of the Track name AutoCorrect and record-Level Locking properties. I don't recall seeing these discussed anywhere else (or perhaps I was not paying attention).
The 'Track name AutoCorrect info' is one of those debatable issues. Used to be an issue, not sure it still remains one, but since I never use the feature, I disable it by habit. As for Record-Level Locking it is shocking the impact it can have one a database's file size! It's one change all developers should implement. I learnt about it from a discussion where Albert Kallal explained it to someone having bloating issues.
This is very helpful... thank you so much... learned so much with you explaining it via video vs text... any tips to optimize queries? As well as dao vs ado recordset?
Nope. Access remains an excellent option! "Real databases", oh please. Microsoft Access remains ('one of the' - some people had an issue with the statement) the most widely used database in the world. It drives most businesses (even when management and IT don't realize it!). Heck, I don't know if it is still the case, but at one time QuickBooks, used by thousands of not millions of people, was an Access database! And I can give countless more examples of Access being just fine as a database. Access is one of the grandfathers of databases, brought mouse/GUI design to the database world and 30+ years later is still going. Like all tools, you need to know how to effectively work with it to get the most out of it. You also have to properly assess the requirements of each project and select the proper tool for the job. Access remains an excellent choice for a great many projects. Add to that the fact that many of these best practices apply to any database in reality, not just Access!!! Typically, those having issues with performance, file size and various other issues are those who simply ignore such best practices and choose to ignore advice!
@@DanielPineault You wouldn't just go on the internet and tell lies would you? I am a billion percent certain SQLite is used WAAAAAAY more than Access. More than a trillion SQLite databases exist.
Now you wish to insult me, call into question my morals and ethics. Nothing to actually argue the issue you brought forth so now you try attacking me. Sad. I have no issue having real discussions, but this isn't one the way you have choosen to act. I see where this is headed. No point continuing any further. Take care.
Nope. Every database has issues and best practices, that doesn't mean that Access isn't a great system. Like everything else, it's about mastering the tool so we get the most out of it with the least issues and effort. Add to that the fact that several of these rules apply to any database, not just Access! Then there's the whole distinction between back-end vs front-end, where Access typically can't be beat on the front-end side of things.
In a front/backend solution you can have many backends. Think of access, excel, sqlite, oracle, SQLserver etc.. all tied to 1 frontend. SQLserver is promoted as the preferred backend by microsoft. I even had a project where AZURE-sqlserver was the backend.
This is an amazing video. It's exactly what so many of us need to see, and refer back to often.
Thank you for those kind words and thank you for taking the time to post your feedback. I truly appreciate it.
Each one of these rules deserves its own 10 minute video. And worthy of argument on the nuances. Each developer encounters their own unique challenges which may require variations on these rules but these are a very good start.
Agreed, I could easily expand on most, but I was trying to make a smaller, more easily digestible overview video. Sometimes less is more. I'm hoping this was one of those cases.
Nice compilation, most of which i knew and follow follow. The one about one subform to hold a graphic was new to me.
I was amused by how many consist of turning off various conveniences that access provides.
Glad you enjoyed it!
Thanks for supplying the attachment method database as a download, this saves me a ton of time trying to workout it out for myself the way that it is demonstrated in the db download (method 2)
My pleasure and glad you found it helpful.
Awesome, thanks for sharing your guidelines and best practices. Very helpful.
My pleasure.
Thank you for the basics reminder, I have learned a few of the pitfalls.
Glad it was helpful!
I agree with you 100% of your advices. I also use a couple of features (with no issues) that you don't talk about:
1) Calculated fields on tables
2) Data macros
Many access developers claim that they don't have to be used, but I dissagree with them.
I avoid both. In the right hands they are fine, but I still like to do calculations in queries and data changes and trigger them myself. There also the issue of upsizing to other RDMS with such feature implemented. But many use them and love them.
Good on you 👍👏
Thank you
Thanks Daniel, I learned something new today. I was not previously aware of the Track name AutoCorrect and record-Level Locking properties. I don't recall seeing these discussed anywhere else (or perhaps I was not paying attention).
The 'Track name AutoCorrect info' is one of those debatable issues. Used to be an issue, not sure it still remains one, but since I never use the feature, I disable it by habit.
As for Record-Level Locking it is shocking the impact it can have one a database's file size! It's one change all developers should implement. I learnt about it from a discussion where Albert Kallal explained it to someone having bloating issues.
This is very helpful... thank you so much... learned so much with you explaining it via video vs text... any tips to optimize queries? As well as dao vs ado recordset?
Thank you for the feedback. I've noted the suggestions for future videos.
my access database is very slow as search in list box or barcode reader its about 50k records plz guid me.
Slow? How exactly is it slow?
I'd recommend posting in a good forum. Currently I'm privileging Experts Exchange.
√√√
Thank you
Quite certain best practice is NOT to use Microsoft Access. Real databases exist, and for all other needs just do SQlite.
Nope.
Access remains an excellent option!
"Real databases", oh please. Microsoft Access remains ('one of the' - some people had an issue with the statement) the most widely used database in the world. It drives most businesses (even when management and IT don't realize it!). Heck, I don't know if it is still the case, but at one time QuickBooks, used by thousands of not millions of people, was an Access database! And I can give countless more examples of Access being just fine as a database. Access is one of the grandfathers of databases, brought mouse/GUI design to the database world and 30+ years later is still going.
Like all tools, you need to know how to effectively work with it to get the most out of it. You also have to properly assess the requirements of each project and select the proper tool for the job. Access remains an excellent choice for a great many projects.
Add to that the fact that many of these best practices apply to any database in reality, not just Access!!!
Typically, those having issues with performance, file size and various other issues are those who simply ignore such best practices and choose to ignore advice!
The people who don't like Access are usually the ones who don't understand Access.
@@DanielPineault You wouldn't just go on the internet and tell lies would you? I am a billion percent certain SQLite is used WAAAAAAY more than Access. More than a trillion SQLite databases exist.
Now you wish to insult me, call into question my morals and ethics. Nothing to actually argue the issue you brought forth so now you try attacking me. Sad. I have no issue having real discussions, but this isn't one the way you have choosen to act. I see where this is headed. No point continuing any further. Take care.
Microsoft Access - Best Practices = Don't use it, use a real database
Nope.
Every database has issues and best practices, that doesn't mean that Access isn't a great system. Like everything else, it's about mastering the tool so we get the most out of it with the least issues and effort.
Add to that the fact that several of these rules apply to any database, not just Access! Then there's the whole distinction between back-end vs front-end, where Access typically can't be beat on the front-end side of things.
SMH
In a front/backend solution you can have many backends. Think of access, excel, sqlite, oracle, SQLserver etc.. all tied to 1 frontend. SQLserver is promoted as the preferred backend by microsoft. I even had a project where AZURE-sqlserver was the backend.