Teaching users to fish--an online intro to queries

Published 03 December 07 10:27 PM

Does this sound familiar? Smart Access user builds a cool database to help co-workers do their jobs more efficiently. Co-workers sing praises and advocate a raise for the smart Access hero. A few weeks later, end users ask hero to help create a couple queries and reports to answer more complex business questions. Hero has three choices:

  1. Tell them to get lost and lose new-found hero status.
  2. Write the query for end users and thus, assume new roll as team Access developer.
  3. Teach end users how to fish. 

I’m a big fan of teaching people to fish.

The end user assistance team has been hard at work improving the most commonly accessed help topics. They recently updated Introduction to queries with new content and the following five wildly popular demos for visual learners:

  • Look at a subset of the data in a table
  • Review data from more than one table simultaneously
  • Ask variations of a question by using parameters with a query
  • Make calculations based on your data
  • Look at summarized or aggregate data

Next time your co-workers want you to help them answer a business question with a query—send them a link to the help topic and teach them to fish. They will feel empowered with new-found technical chops.

by clintc
Filed under: ,

Comments

# Tony Toews said on December 4, 2007 8:58 PM:

Where I do have power users I will give them a query only MDB linked to all the tables in the back end mdb/accdb.   I put in some basic example queries pulling in data from several tables.  This then becomes their query "play ground".

However you have to hope and trust your users never run an action query.  (Especially if Cascade Deletes are being used.  Which I never use anyhow.)

I'd really like to see some means of ensuring read only ad hoc access to the back end data mdb/accdb yet allowing the "official" front end mde/accde full access to the back end.

# Craig Alexander Morrison said on December 5, 2007 8:37 AM:

You could generate a "playground" (aka Data Warehouse) for the users. That is a copy of the live data in another mdb and this can be "flattened".

Giving users direct access should be avoided at all costs. Although hardly advanced security, sticking a database password on the central database should prevent all but your MDEs getting at the live data.

Teach them to fish but don't allow them to use dynamite just a rod.

New Comments to this post are disabled
Page view tracker