Wrox Programmer Forums
|
Access VBA Discuss using VBA for Access programming.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Access VBA section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old September 19th, 2003, 11:51 AM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

Hi Phil,

Cool add-in. If you bump into an ADO.NET version of the same let us know. Actually doesn't look like it would be too hard to re-write. Just need to figure out which intefeace .NET add-ins have to implement instead of IDTExtensibility? or maybe it can run in a .NET app via COM interop? Thanks for the download.

Bob

 
Old September 19th, 2003, 01:04 PM
Authorized User
 
Join Date: Sep 2003
Posts: 17
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Thanks guys, I really appreciate all your help! I'm looking forward to getting some reading material and getting started.

Sean

 
Old September 20th, 2003, 06:14 AM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 120
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Sean

Am I correct in thinking that you're not coming from a programming background?

If I am, can I recommend that you spend at least half of your learning time discovering how to program well, and all the other processes and practices that will make you a good software designer?

You can know your chosen language inside and out and still write absolutly stinking programs.

I've no book recommendations to give, as it's a long time since I did my degree - but what I learnt has been relevant all through my computing career.


Brian Skelton
Braxis Computer Services Ltd.
 
Old September 22nd, 2003, 03:06 AM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 1,212
Thanks: 0
Thanked 1 Time in 1 Post
Default

Quote:
quote:Originally posted by Bob Bedell
 Hi Phil,

Cool add-in. If you bump into an ADO.NET version of the same let us know. Actually doesn't look like it would be too hard to re-write. Just need to figure out which intefeace .NET add-ins have to implement instead of IDTExtensibility? or maybe it can run in a .NET app via COM interop? Thanks for the download.

Bob
Hi Bob,
I'm not using .NET currently, but maybe this article will help you figure out how to write a .NET add-in.
http://www.fawcette.com/vsm/2002_10/...ktopdeveloper/

rgds
Phil
 
Old September 22nd, 2003, 08:32 AM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

Thanks Phil,

Turns out I have that issue of VS Mag (used to be Visual Basic Developers Journal). Thanks for the code. :)

Bob

 
Old September 22nd, 2003, 09:39 AM
Authorized User
 
Join Date: Sep 2003
Posts: 17
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Braxis -
Answering your question...No, My formal education is not in programming; it is in finance and economics. I am more inclined to agree with you on

Quote:
quote:Originally posted by Braxis
 Sean
You can know your chosen language inside and out and still write absolutly stinking programs.
Since we are working with data and numbers most of the time in business to illustrate trends, manipulate, disseminate and forecast - database programming is what we rely on to accomplish business scenarios. I realized this many years ago while still at the University and working as an engineer. I started with automating Excel spreads for accounting and marketing and soon realized the potential of Access and VBA. So I figured, what more can I do as a programmer but to try and learn all of the idiosyncrasies of the language. I have written some pretty stinking programs that were not optimal, but as I learned more my apps began to run efficient through efficient code. Yet, that is not to say the programs did not achieve their objective, they did indeed. The proof was in the puddin'- the user was happy and the app did what we set out to do.

Now - I am certain that there have been apps that I have written that can be improved, but my initial question was - where do I go from here? What if I develop an application in Access that the entire staff of the organization have the potential to access at the same time. Well, then I don't think Access is the route to go. After some thoughtful advise, I think I am on the right track in learning VB.net and SQL server, together, to accomplish my database designing needs.

I bought a book several months back - Visual Basic.Net Database programming by Evangelos Petroutos and CYBEX publishing. I just started it and I find it to be very informative. I think VB.Net is the route to go, i.e. to grow as a programmer and to step up to the latest technologies.

But if I may ask, what specifically - if you would be generous enough to share - are some of the processes and practices I can implement, as I continue to learn, that will make me a good software designer?

Quote:
quote:Originally posted by Braxis
 Sean
If I am, can I recommend that you spend at least half of your learning time discovering how to program well, and all the other processes and practices that will make you a good software designer?
I appreciate your advise and comments. Any thoughts you have would be a benefit to me. Thanks again for your help. :D

Sean

 
Old September 22nd, 2003, 05:28 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 120
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Sean

Sincerest apologies if I've come across as patronising - it wasn't my intention at all. But I have had to maintain, and have undoubtedly written, some appallingly badly designed programs.

Especially, I have to disagree with this:
 
Quote:
quote:The proof was in the puddin'- the user was happy and the app did what we set out to do.

User happiness is an important and, all to often, elusive goal - but not always the prime one. I've never designed a system that hasn't changed & grown once released, so scalabilty and maintainability are usually near the top of the list. Even the most basic system has to be looked after by someone, and it may well be you that has to do it!

Anyway, here's a list, incomplete and in no particular order, of the things I've found useful, or wished I knew more about:
  • Relational database design
  • Code modularisation
  • Extracting Requirements from users
  • OO design principles
  • Data Protection law
  • Code reuse
  • Disaster recovery procedures
  • Collaborative software design
  • Automated error tracking
  • Keeping users enthusiastic
  • Formal documentation
  • Good user interface design
  • 'Black Box' programming
  • Selling technical solutions to management
  • Help file authoring
  • Creating test plans
  • Effective data backup
  • Manual fallback procedures
  • Managing test teams
  • Coding standards
  • Naming conventions
  • Network security
  • Disability law
  • Costing software
  • Refusing user requests
  • Database security
  • Formal specification
  • Process writing
To finish off, here's an extremely :D piece that covers a few of the points mentioned above http://mindprod.com/unmain.html


Brian Skelton
Braxis Computer Services Ltd.
 
Old September 22nd, 2003, 08:43 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

Hi Sean,

I can’t resist the impulse to add one concept to Brian’s excellent list. It’s actually more a generalization than an addition in that it incorporates concepts like code modularization, OO design principles, code reuse (and lets not forget maintainability), and Black Box programming.

What I have in mind is the idea that well designed applications will implement a “logical n-tier architecture”, that is, they will separate functionality into well defined roles or groups in order to increase code clarity and maintainability. There are many ways to accomplish this goal, but its good to work with at least the following four divisions in mind:

 
  • User Interface code– that accepts user input and then provides it to the business logic (this is where your windows forms or web forms live).
  • Business Logic code – that includes business rules, data validation, manipulation, and processing (this is where your business objects live).
  • Data Access code – that interacts with the data management tier (DBMS) to retrieve, update, and delete data (this is where ADO/ADO.NET objects live).
  • Data Storage and Management – that handles the physical creation, retrieval, update, and deletion of data (this is your DBMS, such as SQL Server).


The emphasis here is on logical architecture. The UI, Business Logic, and Data Access code can all reside in a single project on a single computer, but each ‘tier’ is encapsulated in one or more class modules that provide a specific type or functionality. Tiers communicate with one another by calling the methods of classes in other tiers. Also, these are not hard and fast divisions. For example, you may have data validation occurring at the UI, business logic, and data storage tiers. The idea is simply to achieve as much logical separation between types of functionality as possible.

This approach will save you hours and hours of coding by enhancing your codes reuseability and maintainability. The idea is to work at building a code base, or framework, that you can write once, and implement over and over again. For example, a well designed framework won’t even care what type of interface it is communicating with (windows forms or web forms). The UI simply calls methods of objects residing in the business tier, but is oblivious to the implementation details of those methods. The same relationship obtains at lower levels of the architecture.

In short, classes should be the building blocks of your programs. Dlls/assemblies that contain your classes in a compiled state are your units of deployment. So its real important to familiarize yourself with the fundamentals of class design, and object-oriented programming principles in general. Unlike VB 6, VB.NET finally offers all the features that anyone would expect from a mature object-oriented language. All the .NET languages are born equal in this respect, so VB.NET is a fine language to build truly object-oriented programs with.

Regards,

Bob


 
Old September 23rd, 2003, 04:18 AM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 1,212
Thanks: 0
Thanked 1 Time in 1 Post
Default

Don't forget about debugging too. there are loads of books/articles about designing/programming but ones about debugging are rare. the more coding you do, the more time you'll spend debugging, so put some thought into it up front. program defensively - don't assume that files/databases/objects will always be available, for instance. A lot of run-time error messages are very unhelpful, e.g
Type mismatch
ActiveX component can't create object
file not found
permission denied

you'll spend a lot of time tracking down which files/objects etc these sort of errors refer to, so save yourself some time by spending a bit more coding time anticipating problems. Debug.Assert can be your best friend :)

rgds
Phil
 
Old September 23rd, 2003, 01:53 PM
Authorized User
 
Join Date: Sep 2003
Posts: 17
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Brian -
Hey, no problem - I took your comment as good advise, and look how much more dialogue and advise that was generated from your comments. Thanks for you help and opinions. As a beginning programmer, I am always receptive to fundamental concepts and new ideas.

Thanks to everyone for including an extensive list of topics I should learn more about. I am sure this will prove to make me a better programmer.

Many thanks to Brian, Phil and Bob! ;)






Similar Threads
Thread Thread Starter Forum Replies Last Post
Code works in Excel VBA but not Access VBA fossx Access VBA 2 May 21st, 2007 08:00 AM
Access VBA Teqlump Access 2 September 10th, 2004 02:33 PM
Access vba rookieat this Access VBA 6 February 7th, 2004 03:01 PM
Access VBA help danielwajnberg Access VBA 3 September 1st, 2003 09:46 AM
Access XP VBA compatibility issues w/ Access 2000 bourgeois02 Access VBA 1 August 19th, 2003 04:14 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.