I'm also with Dave on this. I have been in 3 of 4 arenas with databases.
The 4 arenas would be the following:

Data Transcriber (I got this experience from when I worked at the IRS
entering data into the system [hence where the name of this arena comes
from] and hated it cause of the break situation at the IRS working the 10
hour shift, which then led to early stages of carpal tunnel syndrome before
I got out of it. Programming was my ticket out of this work.)

Data User (I am very much so in this arena as I rely on the data that is put
into the system. I know I am at times very bull headed about the accuracy
of the data, thus part of the reasons why I put in checks like I have with
the programs I have put into place. Of course the programming work doesn't
fall in this arena, but as a user of the data, the more accurate the data
is, the better of a decision others and I can make.)

Database Programmer (I have had to learn how to build a database and go from
there. However, given our work environment and the limitations of Access, I
can't rely on using Access, so best I can do with Access is use it as a
prototype. For what ever reason, Access losses connection to the server
during the time period when backups are taking place on the server, and we
can't expect our night shift operators to have to restart not only the
program, but also the system nightly on older slower systems. Not only
that, but they don't even get notice of it until they attempt to do
something after connection has been disrupted to the point that it can't be
restored until the system is restarted. For someone in this arena, they
must learn the 6 normalization rules [1NF, 2NF, 3NF, BCNF, 4NF and 5NF],
SQL, how to integrate with other programming languages for the short falls
of SQL, and working with forms with the proper validation codes and in many
cases, learning the events and how to use those events.)

Database Administrator (While I may have some basic experience, I don't have
the official experience in this arena. I have dealt with things that
impacts this arena, so it wouldn't be that hard for me to move into this
arena. One of the areas I have dealt with is security and I really don't
like the security model of Access either on the account of too many issues
with it.)


As a data transcriber, I would like the option at the minimal to back out of
the form just like what Dave said. However, as both a data user relying on
the accuracy of the data and as a database programmer, I would want to have
code put in place to verify the data with all of the necessary checks
(reasonably speaking) before allowing the data transcriber continue on.

--
Thanks,

Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
"Jim McCaffrey" wrote in message
...
Dave - thanks for the information. I'm trying to implement the code you
created and I get an error in the following section - Label1 (method or
data member not found). I wasn't sure where to put the code, so I
created a UserForm1 and put the code there. Is that the right location?

(Private Sub UserForm_Initialize()

Me.Caption = "Enter a value"

With Me.Label1
.Caption = "Please enter a value for: " _
& ActiveCell.Address(0, 0)
.ForeColor = vbRed)
---
This is what I am using to call the UserForm:

If Trim(Range("F11").Value) = "" Then
UserForm1.Show
End If
---


Thanks again.

Jim




*** Sent via Developersdex http://www.developersdex.com ***