Querying the hive mind...

January 11, 2010 6:03 AM

DatabaseFilter: I know more about Access than the average person, but I'm at the point where I need to know more than what I am finding on the Access db sites and in books. I need a faster and more reliable response than I would get from posting on forums.

I have taken two trainings my work paid for, but they were on how to use Access, not how to develop in it. And the next level class (and only one) is about VBA, which I'm not quite at yet.

I feel like I need someone to sit down with me as I go through stuff and say, well, you should do this like this because of this reason. How or where can I get this kind of one-on-one? Even if it were via email or the web, I just need reliable, knowledgeable support in my transition phase.

I've been toying with Access for the last few years and I've gotten pretty good at it. I understand relational db theory to some extent and can certainly set up the tables and all that. But when I get into form design, I tend to get a bit lost. I think I understand queries - I can get the info I want pretty much all the time and can usually figure out my mistakes.

But I need to know if I'm doing things "right" or if I'm making things too hard by doing them my self-taught way.

I did not take any db classes in college and honestly just don't have the time to spend after work going to one now. (I tried last semester and it was a complete disaster and very stressful.)

Do I post on craigslist that I want an Access tutor? How would I verify their skills? I'm pretty sure my work will pay for this, but I just need to find the next level of training I need.

I spent Christmas break with a stack of books from the library, like Access Cookbook and a bunch of others. But I still feel like I'm missing some fundamental things and I don't know what they are.

posted by sio42 to computers & internet (8 answers total)

What specifically are you having problems with? I'm going to guess that you're trying to model data that is simply difficult to model. You don't get over this by getting better at Access, but by working out the mappings in the domain layer of your application. The fact that you're being pushed into VBA is no coincidence, at a certain point relational data is just easier to map using navigational, object oriented methods. The general rule of thumb I use is that persistent data should be an after thought. It is much easier to define your data in the language of your choice and write mappings to the persistent storage.

If you're looking to an introduction into getting simple applications up and running quickly, I highly recommend Rob Conery's ASP.NET MVC Storefront ... this is a multi-part series that goes in depth into explaining why certain decisions are made. As it progresses you begin to see the limitations and ways around certain decisions (which is the true value of the series, in my opinion). There's several design decisions he makes that I don't really agree with or think he could have done much easier, but that's sort of what the comment section and feedback is about.

Even with best practices there's often not a right way or wrong way to do something. It seems like there's more of a divide on what works and what does not work ... and what works down the road as the application takes on more complexity. If you get bogged down on the "right" way of doing things, especially when you're on your own, you can really sink a project by never getting anything done.

In any case, if you're starting out from scratch I would learn C# and not VBA. There are simply more examples in C# than VB, even if the languages aren't that different in functionality or performance.
posted by geoff. at 7:48 AM on January 11, 2010

thanks geoff -

i guess it's that i don't really know what i'm having problems with - i just get to certain points and i can't do what i want and i don't even know how to explain it.

at my job we use Access 2003, so i would be using VBA. i don't think i would run into C# at all. i'm not really a programmer but i'm admin asst in the IT dept and am trying to create some of my own dbs for some of our more complicated invoice tracking.

honestly, i don't even know what a domain layer of an application is. i really don't have years to learn this stuff. can't i just download it to my brain? ha ha. i'm not sure i'm even creating an application - it's just a db for me to use and other people would be able to access it for reports etc.

i would say it's forms that get me, but everything i find about forms is about design like layout, not how to get the info in there. i just end up in a pile of misery of not being able to figure out WHAT is wrong and there's no one here who has enough time to help me. or if they do try to help, the stuff they say makes zero sense.

i need to make some kind of conceptual leap from user to programmer and i don't even know what that is.
posted by sio42 at 8:08 AM on January 11, 2010

i need to make some kind of conceptual leap from user to programmer and i don't even know what that is.

This is probably what you need to focus on. Of course you have the real business problem of doing this complicated invoice tracking. I would first get a subscription to Safari Books and hopefully you can find enough cookbook examples to get the project done.

I have not seen any intro-level programming courses which interact with a database, and this might be what is throwing you off. Unfortunately there's no way around this, you'll need to learn the fundamentals of object oriented programming.

It is entirely possible to get a cursory grasp of computer science using what's freely available on the Internet. I recommend walking through Rob Conery's MVC Storefront in which he walks through, via screencasts, how to build an application from the ground up. I would recommend it in conjunction with the introductory courses at Stanford and MIT. I'd advocated those resources before, and I still think they're great. Rob Conery's project will provide the "This is where I want to be," when going through the rather abstract and dry academic theory.

Access is very good, but you hit a point where what you're doing is just too complex to be done well in Access. The more complex your application the less likely using Access will be helpful to you.
posted by geoff. at 8:40 AM on January 11, 2010

Have you read Database DesignFor Mere Mortals? (Sorry no link, I'm on a phone.)

I used to think about teaching a class to people who are precisely in your situation (especially admin assts, since I used to be one).
posted by matildaben at 9:10 AM on January 11, 2010

geoff - so maybe taking the VBA class at the computer training place i went to before would be a good next move?

matildaben - i have not been able to find it any library and i'm hesitant to throw down for it without being able to check it out in person first. i'll have to start checking the local bookstores and see what their return policies are.
posted by sio42 at 9:16 AM on January 11, 2010

I found that the Apress "Beginning Database Design" and "Beginning SQL Queries" are incredible resources for learning how to model relational databases. It's fairly system-agnostic, but will be fine for Access. Basically, if your model isn't built correctly, no amount of SQL ninjitsu will get the data out in the way you want it.
posted by georg_cantor at 11:09 AM on January 11, 2010

is modeling more than normalizing tables?

cause i seem to have my tables normalized pretty well.
i've been trying to make the same db for the last year, on and off when i have time.
i've been through several designs and table set ups and think i finally have it right.

is this modeling something that comes after normalization?
posted by sio42 at 11:20 AM on January 11, 2010

Once you have tables/relationships and SQL more-or-less in hand, the thing to focus on is form design. Dealing with forms will force you to start to understand events, controls, and how to use VBA here and there to make Access do what you want it to do. Command buttons are your friend. You can use them to trigger queries, pulling values from the form itself. You can find generic books about table and query design, but the trick to using Access well is to learn how to think like Access thinks. Access gives you some useful tools, but combining them into a usable application takes a lot of practice. For me, at least, it's been a real learn-by-doing sort of thing. O'Reilly and Wrox have some good books worth checking out, but there's not a particular book I can point to with confidence and say, "this is the one that will unlock Access' secrets for you!"
posted by wheat at 10:57 PM on January 11, 2010