Need to Tab

RaunLGoode

Registered User.
Local time
Today, 06:20
Joined
Feb 18, 2004
Messages
122
I use Access 2000 on a Win2K box.
I have a form with seven fields. It is a pain to fill out because the values consist of long strings of alphanumeric characters. (I have no control over this) Frequently only one or two values change so I would like to let the user duplicate a previous record and change one or two fields, avoiding redundant data entry
The problem is; if I select the "Duplicate Record" command, and try to move to a new field with my mouse, I get the following error:

"The changes you requested to the table were not successful because they would create duplicate values in the index primary index or relationship…"

If the Tab or Enter key is hit before using the mouse everything works fine. Access does not let me save the duplicate record unless I change a value to make the record unique. The simplest solution seems to be embedding a Tab or Enter action at the end of the code generated for the Duplicate Record command. I can't figure out how to do that? I have enclosed the basic code for the Delicate Record command with where I think the Tab or Enter action should occur

Private Sub cmdCopyRec_Click()
On Error GoTo Err_cmdCopyRec_Click


DoCmd.GoToRecord , , acNewRec

Exit_cmdCopyRec_Click:
Exit Sub

Err_cmdCopyRec_Click:
MsgBox Err.Description
Resume Exit_cmdCopyRec_Click

[This is where I think the Tab or Enter action should occur]

End Sub

Thanks,
 
Reply

This will get me there, but what is the proper prefix for declaring a variable, type Date (mm/dd/yyyy). The only resource I could find had three letter prefixes. dtm, str, vnt, etc. The example seems to use one letter descriptors
 
Raun,

When you declare variables:

Dim strSomeString As String
Dim lngSomeLong As Long

There are two factors to consider. The first declaration explicitly declares
that strSomeString is a string. Its name also indicates that it is a string
because of the "str". The "str" means nothing to Access, but a human
encountering strSomeString knows that it is a string.

If I had a date field for the Date Received, I'd call it either:

Dim DateReceived As Date
Dim dtmDateReceived As Date

Both are explicitly typed as dates, and if encountered in a block of code,
both are obviously dates. The "dtm" just helps people know.

If you ran accross lngTemp and Temp, its easy to see that the lngTemp
is declared as Long, while Temp conveys no meaning.

The important thing is to name them something that conveys what
type of data it is, and what it's meaning is. Field4, while legal, helps
nobody.

Wayne
 

Users who are viewing this thread

Back
Top Bottom