By Richard Rost 14 months ago
When Asking a Question, it's All About Context
This is literally a question I was asked not too long ago in a Microsoft Access group I belong to:
I'm trying to edit my tPetl55 field and look up the SupervisorML from the system table, but the lookup isn't matching. How can I enter a new value and bring back the next row from my Markup data?
To which all I could do was shake my head and reply, "huh?"
Folks, if you're going to ask a question, post something in the Forums, or participate in any kind of conversation, you have to both understand each other. Now, I understand Access. I know databases. I don't know YOUR database. I don't know what YOUR fields mean. I don't know YOUR tables. I might not even know YOUR business and how your processes work. Unless you're modifying a database that I built in one of my classes, I likely have no clue what you're talking about.
I've been building Access databases as a consultant and as a teacher since 1994. Damn, that's almost 30 years now. By far, the hardest thing to do is to try to understand the client's business model and work flow. When I used to build a custom database for a client, the first thing I would do was to sit down with them and go over how their business works and what their current old system does (paper, Excel sheets, whatever). Without a complete understanding of their needs, I couldn't build them the proper database. In some instances I've asked them to change their processes to accomodate the new technology - to make them more efficient. In other cases, I've had to do weird stuff with the database to accomodate their workflow. It's a give and take.
This is one of the problems with helping other people with their database problems. Like I said, if you're working off of one of my class databases, and you say "how can I look up the most recent order on the CustomerF with a dropdown?" then I know exactly what you're talking about and can instruct you accordingly. If you ask a question like the one I posed above, I'll have no clue what you're talking about. Take the question I just asked and substitute meaningless names, it becomes unanswerable. See for yourself:
How can I look up the most recent BlarbP242 on the PX434 with a dropdown?
See what I mean? Not only are the field and form names meaningless to me, but what do you mean by "look up?" You need to get your terminologies straight too. This comes with a little education, yes, but try to use Access terms. If you're using Access, speak in Access terms. I know a lot of people are much more used to Excel, but this ain't Excel. I cover this stuff in my Beginner classes:
Also, explain what you're trying to do. "How can I look up?" doesn't tell me much. Do you want to display details from that order in a text box? Do you want to open the order form? What? The question at the top... what do you mean by "bring back?" I get that a lot. "Bring back" is meaningless. Do you want to display that information as a calculated field in a query or do you actually want to store that data in the table? Huge difference in implementation AND skill level.
This is one of the reasons why I recently posted on my Consulting page that I'm no longer accepting any troubleshooting work, or jobs where I have to add to or fix other peoples' databases. I may accept work like this from time to time, but it's not work that I enjoy doing, and therefore my rates for this kind of work have gone way up. Sorry. I'm happy to help you on databases that I've built (or that you've built following along with my lessons). But I really hate working on other peoples' databases. Almost as much as I hate talking on the phone.
So when you're asking a question, do not assume I understand your business or know your database at all. Use terms to which EVERYONE can relate. Customers and orders is perfect. Drivers and vehicles. Vendors to products. Students to classes. Something that everyone has experience with. I get people with databases ALL THE TIME who ask me how to do things with forms and fields that are specific to their database, and I have no clue what they mean. It would be quicker and easier for you to translate your terms into something relatable than it would be for me to learn your whole business or decipher your terms.
Keep it short and simple. I really don't want to have to read 5 paragraphs of meaningless information just to get to the heart of the matter. Give me as little information as possible but enough information so that I can answer your question. If I get an email from someone and it's as long as this article, I tend to not answer it. If it's a quick "how do I?" and it's something I can crank out in 30 seconds or less, you tend to get your answer.
Spelling and grammar are important! Honestly, if i have to read thru tons of typing that has alot of mispelings and absolutle no punctuashun marks and is just one runon sentense after anothr i tend to ignor it. Now, I understand that English isn't a first language for a lot of you. I get that. But you make my job a lot harder than it needs to be if I have to struggle to read your text. Sorry. Do your best to proof read AND EDIT what you write before you click on that SUBMIT button. Your questions will have a better chance of getting answered.
Table and Field Names Need to be English! Sorry. If you post a question with table and field names like [Client_JPT6_Sub_Action12] half the time I'm not even going to bother to read it. Do me (and all of the other guys on here who answer questions) a favor and translate your crazy field names to things like FirstName, LastName, etc. And do yourself a favor and rename them in your database too! I know that can be a lot of work, but you'll thank yourself later. If it's hard for US to read that, I'm sure it's going to be hard for you 5 years from now.
OK, so that's my rant for today. Sorry. I really want to help people. I do. I spend many hour each week answering questions FOR FREE. But it's so difficult when you don't ask me a question in terms I can relate to. So try to phrase your question as if you're talking to a 3rd grader who doesn't know your business or anything about your database. Use terms that I understand (customers and orders). Use proper spelling and grammar. And keep it short and simple.