Chuck Grimsby <c.*******@worldnet.att.net.invalid> wrote in
news:ke********************************@4ax.com:
Personally however, I'm somewhat against such tests. I've had to
take a few "Electronic/Web based tests" in the past few years, and
everyone of them was absurdly simple, or had answers that were
only valid if you had been trained the "Microsoft way". (How do
you import a text file with the extension '.exp'? Re-name it to
.txt and then use Access' wizard to import the file. Stupid. Why
not just use VBA to open import it? Because that's not "The
Microsoft Way!" <Gack>)
Not so stupid. In certain versions of Access, trying to import a
file with an extension not on the "approved" list will cause the
import to fail with an error indicating that one of the fields
contains data that exceeds the defined size of the field it's being
imported to.
As to questions, I'd consider which topics are important to know.
I'd include something on these:
1. deployment issues -- split databases, etc. -- explain *why* we
split.
2. Access security (note the question is not about *Jet* security)
-- explain the steps to secure a front end vs. a back end. I'd be
looking for someone to know about MDEs, how to set the ByPass key,
as well as the basics of using Jet security and RWOP queries. Also,
it would be good for them to discuss the limitations of securing Jet
data.
3. explain why it's not a good idea to use macros for anything other
than the handful of things that require them. Enumerate which tasks
require macros in which versions of Access (e.g., AutoExec, all
versions, customized menus, A97).
4. ask the programmer to write some fairly basic code, such as a
TableExists() function. There are at least three different ways I
can think to do this (use SQL on MSysObjects, walk the TableDefs
collection or try to open the TableDef and use error handling to
determine if it doesn't exist). Explicitly require error handling in
the function. Require comments, consistent naming conventions and
error handling.
5. explain the value of naming conventions in coding.
6. explain when unbound forms are useful. Explain why it's probably
not a good idea for all forms to be unbound.
7. what are the issues to consider when choosing a back end? When is
Jet inappropriate?
8. discuss the differences between DAO and ADO and when each is
appropriate. Have them explain how to use both in a single
application.
9. describe 1 (or 2 or 3) scenario(s) where using transactions is
required.
10. explain the difference between a primary key and a foreign key.
Discuss what indexes are involved in Jet and how these interact with
defined relationships.
11. discuss the issues involved in choosing natural keys vs.
surrogate keys.
12. ask them to map out a rough schema for a particular application,
maybe an invoicing system, or something relatively standard.
13. outline the relative advantages/disadvantages in various
situations of data validation:
a. at the table level
b. at the form's record level
c. at the form's control level (should include a discussion of
choosing the proper control type, rather than just delving into
using code in the BeforeUpdate event)
14. give some examples of some fields and ask which control should
be used for it.
15. have the programmer write some pseudo code to open a dialog form
to collect some criteria for filtering a report or form. Have them
explain where in the form or report the code should be run from.
They will need to describe the dialog form and the code behind it,
as well.
16. discuss the uses of class modules and where they are
appropriately used. Perhaps have them map out the basics of a pseudo
class to accomplish a certain task. A good examply might be an
OpenForm class that can be used to open multiple instances of a
single form, and that can open forms that require opening arguments.
If the environment you're working in requires SQL Server, you should
probably ask them some questions specific to that, such as security,
stored procedures, optimization, and so forth.
Does that help, Trevor? I certainly wouldn't want to grade a paper
test with questions like this -- I'd do it all verbally with a
whiteboard or lots of pen and paper handy. And for the coding, for
some people it's easier to work in real Access, and I'd allow them
to do it at the keyboard, rather than making them do it in the
abstract. If, however, you go the abstract route, you've got to be
more forgiving of small errors in syntax and go more for structure.
In fact, I'd say that basically any 5 of the questions above should
tell you what level someone is.
--
David W. Fenton
http://www.bway.net/~dfenton
dfenton at bway dot net
http://www.bway.net/~dfassoc 
