-
If you would like to post, please check out the MrExcel Message Board FAQ and register here. If you forgot your password, you can reset your password.
Access Knowledge
- Thread starter drock99a
- Start date
Aladin Akyurek
MrExcel MVP
- Joined
- Feb 14, 2002
- Messages
- 85,210
1) Normalization;
2) SQL/Query Grid;
3) VBA.
2) SQL/Query Grid;
3) VBA.
Upvote
0
My particular path was:
SQL
Macro (short)
VBA
Normalization (Structure of Database)
I learned basics, how to do stuff and SQL syntax, went to Macros to automate repeated tasks, then VBA when I realized it didn't allow any real logic to be used. Normalization and structure came later, after I understood the tools.
My recommendation for self-learning is, search. Don't always ask on forums. Search and browse sites with code examples. Eventually, the more you do, the more likely you'll come back to one or more of them because there was something there that's going to help you today.
Mike
SQL
Macro (short)
VBA
Normalization (Structure of Database)
I learned basics, how to do stuff and SQL syntax, went to Macros to automate repeated tasks, then VBA when I realized it didn't allow any real logic to be used. Normalization and structure came later, after I understood the tools.
My recommendation for self-learning is, search. Don't always ask on forums. Search and browse sites with code examples. Eventually, the more you do, the more likely you'll come back to one or more of them because there was something there that's going to help you today.
Mike
Upvote
0
Abulafia
Board Regular
- Joined
- Jun 15, 2004
- Messages
- 66
In my opinion you should build your database in this order:
Tables
Queries
Forms
Reports
Tables involves learning how to normalise your data and you should not think about doing anything else with your database until you have a hermetic table structure.
I wouldn't particularly say that you have to learn SQL as the Query Design Grid (or the wizards) can help you do most manners of queries - all you have to do is reference them. For more specific queries then it would certainly pay to learn SQL (it isn't that hard) when trying a UNION or selecting the TOP 10 PERCENT rather than all records.
A big mistake that people make is they bind forms to tables - they should be bound to queries. With a query you can load in one record to the form whereas, if you bind to a 1,000,000 record table then you load all 1,000,000 records into the form each time and this is detrimental to speed (network people don't like this either) :D
With forms, learn to prefix all your objects. txt for textbox, lst for listbox, etc. so that when you bind control to fields one doesn't override the other - this happens if both a field and a control have the same name. Learn to do a consistent design - don't have a button at the top left on one form and then on the bottom right when it performs the same function. Don't go stupid with graphics and if you do need any keep them small and to a minimum. Consult potential users about the form's colour scheme as they are the ones who have to use it and, grey is always the safe bet with splashes of no more than three other colours (that complement!)
Reports, just define your output. Base them on the queries too. Stick to the same prefix rule for objects.
VBA should be your last resort. It will help to add functionality to your database; most inexperienced programmers, however, go overboard with this (i.e. creating static queries in VBA) without realising the consequences.
If you plan on having macros in your database though then learn VBA and you can cut out the macros altogether - they are slow and have no means of error handling/trapping. A quick way to get a taste for VBA is to create a macro and then convert it to VBA to see how the keywords are used.
Tables
Queries
Forms
Reports
Tables involves learning how to normalise your data and you should not think about doing anything else with your database until you have a hermetic table structure.
I wouldn't particularly say that you have to learn SQL as the Query Design Grid (or the wizards) can help you do most manners of queries - all you have to do is reference them. For more specific queries then it would certainly pay to learn SQL (it isn't that hard) when trying a UNION or selecting the TOP 10 PERCENT rather than all records.
A big mistake that people make is they bind forms to tables - they should be bound to queries. With a query you can load in one record to the form whereas, if you bind to a 1,000,000 record table then you load all 1,000,000 records into the form each time and this is detrimental to speed (network people don't like this either) :D
With forms, learn to prefix all your objects. txt for textbox, lst for listbox, etc. so that when you bind control to fields one doesn't override the other - this happens if both a field and a control have the same name. Learn to do a consistent design - don't have a button at the top left on one form and then on the bottom right when it performs the same function. Don't go stupid with graphics and if you do need any keep them small and to a minimum. Consult potential users about the form's colour scheme as they are the ones who have to use it and, grey is always the safe bet with splashes of no more than three other colours (that complement!)
Reports, just define your output. Base them on the queries too. Stick to the same prefix rule for objects.
VBA should be your last resort. It will help to add functionality to your database; most inexperienced programmers, however, go overboard with this (i.e. creating static queries in VBA) without realising the consequences.
If you plan on having macros in your database though then learn VBA and you can cut out the macros altogether - they are slow and have no means of error handling/trapping. A quick way to get a taste for VBA is to create a macro and then convert it to VBA to see how the keywords are used.
Upvote
0
Similar threads
- Solved
