Computer Learning Zone CLZ Access Excel Word Windows

Let us pick up our books and our pens. They are our most powerful weapons. One child, one teacher, one book and one pen can change the world.

-Malala Yousafzai
 
Home   Courses   Seminars   Templates   Help   TechHelp   Forums   Contact   Join   Order   Logon  
 
Home > Context
 
All About Context
By Richard Rost   Richard Rost on Twitter Richard Rost on LinkedIn Email Richard Rost   9 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:

  • Record not Row
  • Field not Column
  • Combo Box not Dropdown
  • Forms are on the screen
  • Reports are for printing

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.

Love you.

 

GainsLoss based on FIFO Upload Images   Link  
Zohair Ghadiali 
9 months ago
How do I formulate the access query to calculate the Gains or Loss based on FIFO method in Inventory management? vba coding is also acceptable.
Richard Rost
9 months ago
LOL
Add a Reply

Start a NEW Conversation
 
Only students may post right now. Click here for more information on how you can set up an account. If you are a student, please LOG ON first.
 
Subscribe
 
 

Learn
 
Access - index
Excel - index
Word - index
Windows - index
PowerPoint - index
Photoshop - index
Visual Basic - index
ASP - index
Seminars
More...
Customers
 
Account Login
Online Theater
Downloads
Lost Password
Memberships
Student Databases
Change Email
Info
 
Latest News
New Releases
User Forums
Topic Glossary
Tips & Tricks
Search The Site
Code Vault
Collapse Menus
Help
 
Customer Support
Web Site Tour
FAQs
TechHelp
Consulting Services
About
 
Background
Testimonials
Jobs
Affiliate Program
Richard Rost
Free Lessons
Mailing List
Order
 
Video Tutorials
Handbooks
Memberships
Learning Connection
Idiot's Guide to Excel
Volume Discounts
Payment Info
Shipping
Terms of Sale
Contact
 
Contact Info
Support Policy
Email Richard
Mailing Address
Phone Number
Fax Number
Course Survey
Blog RSS Feed    Twitter

YouTube Channel    LinkedIn
Keywords: terms terminology access terms access terminology  PermaLink