Here's one for all the Forum Guru's...

[MackMan]

Now I know us mere mortals on Access can be a pain in rear for those that have all the knowledge. But I was thinking...

What was it/ what choice did you take to become so successful in Access?
Is there any structured method of learning VBA, SQL etc?
I'd like to know as it's something I'm getting more and more into, and not only that, already I've learnt a ton of stuff from the top contributors on these forums, and I AM extremely grateful.

So yeah, how'd you get into Access / VBA / SQL?

 

[RainLover]

Read a very basic book and search the internet for tutorials. make sure you do them and understand.

Ask if you don't understand.

 

[Frothingslosh]

How did I get into it?

I was working as a CAD operator and brought into a meeting including management, the network admin, and the staff programmer.

"Frothingslosh," I was asked by the CEO, "I hear you're good with computers. Is that true?"
"I like to think so", said I.
"Do you know Access?"
"No, but I'm sure I can learn it."
*CEO slides a stack of M$ books at me*
"Good, we need a project tracking system by Friday."

 

[RainLover]

I hope he gave you the choice of which Friday.

 

[CJ_London]

Have a project you are interested in
break it down into manageable portions
understand what each portion is required to do
keep it simple initially
look at other systems and ask 'how did they do that?'
make use of books and google

But to start
learn the basics of naming conventions, name all objects meaningfully and be consistent in naming (i.e. no spaces, use underscores if you must), in Access it is also common to prefix objects with their type for ease of identification e.g. tbl, qry, cbo etc. This will increase rate of learning as you won't hit issues created by not being consistent.
Don't rely on things like calculated, lookup and multivalue fields - they don't translate to any other system and tables are for storing data, not processing it.
document your code so you can easily understand later what it is supposed to be doing
learn correct terminology and when asking questions refer to objects correctly (i.e. differentiate between a field and a control, they are not the same thing) and don't be vague, you won't be giving any trade secrets away by displaying some code

But you asked about how I/we got into access/vba

I got into it by developing databases in UCSD Pascal - there was nothing like Access available at the time - so I initially created simple text files using sequential searching. This soon proved to be too slow so I learned how to create my own table objects, indexes and pointers and forms, I also had to learn how to manage memory utilisation since memory was very small in those days (just 8k!). My first project was a production management system, handling everything from stock control and production planning to generation of despatch notes and invoicing and management reports. During this process among other things I learned the principles of naming conventions and normalisation.

When Access 97 came out, I was in a new company and Access 97 offered a GUI development environment plus a number of additional features making development much easier so I transitioned from my 'homebuilt' database system. I had learn how access 'did it' compared with what I had done previously and I had a number of features which did not exist in Access so I learned to do it the access way.

 

[Frothingslosh]

It was his idea of a joke.

I actually had around a month, which was plenty of time to learn the system and get SOMETHING up and running. Took another six months to get it down, though. You know the drill - lots of after-the-fact changes, a couple near-total rewrites because they completely changed how they wanted some things handled, things they forgot to tell me they wanted, things Access 2 and SQL couldn't do, that kind of thing. And, of course, less time available because they assigned me to other primary duties instead.

 

[Brianwarnock]

It was his idea of a joke.

I actually had around a month, which was plenty of time to learn the system and get SOMETHING up and running. Took another six months to get it down, though. You know the drill - lots of after-the-fact changes, a couple near-total rewrites because they completely changed how they wanted some things handled, things they forgot to tell me they wanted, things Access 2 and SQL couldn't do, that kind of thing. And, of course, less time available because they assigned me to other primary duties instead.

Pretty standard IT shop then.

Brian

 

[Frothingslosh]

Pretty standard IT shop then.

Brian

Engineering shop, not IT - we built control systems for assembly lines - but otherwise: yup.

 

[pbaldy]

I got started in the late 90's. I was an accountant/computer guy, like many of you the guy with computer aptitude that people came to with questions. All our applications were on an old Alpha Micro system that wasn't going to survive Y2K. The owner's best friend was IT Director at the university, had some knowledge of Access, and said he could recreate some of the applications in Access. I worked with him at first, and soon knew more than he did. Now I'm IT Manager but I probably spend at least 75% of my time creating/maintaining Access/SQL Server apps.

 

[BigHappyDaddy]

While I was getting my Electical Engineering degree, I discovered I had a knack for programming. After school, for reasons I won't get into, I have never had a position as any kind of engineer. Mostly business analysts type / data crunching positions.

I was better than my co-workers at data analysis, but didn't like some of the tedious tasks that come with it. Since I too lazy to continue doing those tedious tasks, I began working on projects to save myself time. Soon those tasks to save myself time grew to developing projects to for my department, then multiple departments and even across divisions.

Programming / database development has never been my primary task, but over time, I have been given "additional" tasks to develop projects. Those projects have become bigger and more complex. Every project has been a great learning experience.

Started in simple Excel spreadsheets as that was what everyone else used. Discovered that spreadsheets are not great at data storage. Ventured out in Access. Slowly at first, but I enjoyed it. Now I am considered one of the better "power users" in our building. I freely admit I can't compete with our professional developers, but I can talk the talk and can easily express the business requirements in terms the developers can easily understand.

 

[Frothingslosh]

I can talk the talk and can easily express the business requirements in terms the developers can easily understand.

I swear to God every company on the planet needs you to work for them.

 

[BigHappyDaddy]

I swear to God every company on the planet needs you to work for them.

LOL! I appreciate that! I can totally understands both sides of the coin (having been on both sides ). It is -oh so frustrating- so see projects ( I am not involved with) sputter along due to poor or mis-communication.

 

[MackMan]

I'm no Guru! but heading up with what CJ mentioned...

Have a project you are interested in
break it down into manageable portions
understand what each portion is required to do
keep it simple initially

I'm truly thankful for what you guys have done in regards to the help, guidance, and more importantly.. [Patience]:banghead:

I'll try not to bug you too much in the future.

 

[Libre]

My entry into Access was similar to Frothingslosh's - that is, from the Engineering field. I was a mechanical designer in an aerospace/defense company (not a CAD operator like Froth, but in a similar capacity). I was promoted to the position of Configuration Manager (don't ask me to explain what that is) but in that position, I had to assign controlled document numbers. What they had at the time (the late 1990's) was a series of books. A person would sign out a number manually. These books were now my responsibility. I hate manual work but I love having work saving ideas and making THEM work. Since I had taken a programming course at the Chubb Institute (and did very well), I decided to automate the process. I thought about a spreadsheet and mentioned this to my boss (picture Dilbert's boss here). The boss said something to the effect of: A SPREADSHEET??!!! This should NOT be a spreadsheet. It should be a database!!
That got me to thinking about databases (at Chubb I had taken a course in DB2 which is the database designed for mainframe COBOL programs, and also a course in Oracle) and I had the concept. I didn't have DB2 or Oracle but I had Access on my computer. I started messing around - having no knowledge of Access but I did understand VBA from having taken Visual Basic and the syntax of VBA was very similar at the time.
I went to town. I fell in love with Access. Like Froth, I was not in the IT dept - where they had dedicated programmers. One of them took me under his wing and made himself available to me. I bought a "dummies" book and a few other basic texts. I created the program and then added to it, bit by bit. I replaced that bookshelf of lame-o log books with an application on all the engineer's desktops. They loved it.

Next job, I designed an entire enterprise software system based on what I had learned at the former job, and the next job after that, I did the same.

Each time, my system was better, more elegant, more functional, more efficient, and more intuitive and friendly to the user.
My basic approach was what was stated above - break down a project into smaller units, understand what is needed and then design a function to do that thing. Then put it all together.

One of the most important things you can do is, once you have something working - BACK IT UP - and then try to break it. Enter totally unexpected inputs in completely the wrong sequence and see what happens - because that is what WILL happen once you put it in the hands of the users.

Anyway, now I'm considered an Access guru - even by the IT dept - although I'm still in Engineering. And I never had so much fun, had such an incredible sandbox, had such a powerful tool to implement my ideas, as MS Access - my favorite computer program of all time.

 

[Mile-O]

When I joined this forum I was just starting out in Access. Think my first post was trying to figure out where I was going wrong with a calendar.

From there people would say read on normalisation, etc, and I did.