Hendra-
Here's the code I promised:
In a Standard module:
--------------------------------------------------------
' Common Form_Error codes
Public Const errCancel As Long = 2501
Public Const errCancel2 As Long = 2001
Public Const errDuplicate As Long = 3022
Public Const errInvalid As Long = 2113
Public Const errValidation As Long = 2116
Public Const errInputMask As Long = 2279
Public Const errRI As Long = 3200
Public Const errCustomValidate As Long = 3316
Public Const errTableValidate As Long = 3317
Public Const errSearchEnd As Long = 8504
Public Const errSpellCheck As Long = 9536
Public Const errGeneral As Long = 3316
Public Const errPropNotFound As Long = 3270
----------------------------------------------------------
In your Form_Error event:
------------------------------------------------
Private Sub Form_Error(DataErr As Integer, Response As Integer)
' This is standard code that I put in the Error event
' of all forms that edit data. The idea is to try to intercept
' most of the common standard error messages - most of which are
' not user-friendly - and deal with them here.
' Pick options based on the error code - see ErrorTable for a complete list
Select Case DataErr
Case errCancel, errCancel2, errPropNotFound ' Cancel - ignore
Response = acDataErrContinue
Case errDuplicate ' Duplicate row - custom error message
MsgBox "You're trying to add a record that already exists. " & _
"Enter a new Employee ID or click Cancel.", vbCritical, gstrAppTitle
Response = acDataErrContinue
Case errInvalid, errInputMask
' Invalid data - custom error and log
MsgBox "You have entered an invalid value. ", vbCritical, gstrAppTitle
ErrorLog Me.Name & "_Error", DataErr, AccessError(DataErr)
Response = acDataErrContinue
' Field validation, Table validation, Custom Validation, End of Search, Spelling Check
Case errValidation, errTableValidate, errCustomValidate, errSearchEnd, errSpellCheck
' Do nothing -- let the standard message display
' All validation rules in the tables have custom error messages.
Response = acDataErrDisplay
Case Else
' Dunno - log and let error display
ErrorLog Me.Name & "_Error", DataErr, AccessError(DataErr)
Response = acDataErrDisplay
End Select
End Sub
----------------------------------------------------
The ErrorLog function:
------------------------------------------------------
Public Sub ErrorLog(strProc As String, ByVal lngErr As Long, ByVal strError As String)
'----------------------------------------------------------
' Inputs: Name of the procedure trapping the error
' Err value
' Error string
' Output: Writes an entry to ErrorLog table
' Created By: JLV 01/31/95
' Last Revised: JLV 01/31/95
'----------------------------------------------------------
Dim db As Database
Dim rstE As Recordset
Dim strFrmName As String
Dim strCtlName As String
Dim lngErrSav As Long
Dim strErrSav As String
On Error Resume Next
lngErrSav = lngErr
strErrSav = strError
Set db = CurrentDb()
Set rstE = db.OpenRecordset("ErrorLog")
rstE.AddNew
strFrmName = Screen.ActiveForm.Name
rstE!CurrentForm = strFrmName
' Added trap to avoid Fault when screen is blank
If Not IsNothing(strFrmName) Then
strCtlName = Screen.ActiveControl.Name
End If
rstE!CurrentControl = strCtlName
rstE!ActiveForms = Forms.Count
rstE!UserName = CurrentUser
rstE!Date = Now
rstE!CallingProcedure = strProc
rstE!ErrorCode = lngErrSav
rstE!ErrorText = strErrSav
rstE.Update
rstE.Close
End Sub
-------------------------------------
John Viescas, author
Microsoft Office Access 2010 Inside Out
Microsoft Office Access 2007 Inside Out
Building Microsoft Access Applications
Microsoft Office Access 2003 Inside Out
SQL Queries for Mere Mortals
http://www.viescas.com/
(Boston, MA)
-----Original Message-----
From: MS_Access_Professionals@yahoogroups.com [mailto:MS_Access_Professionals@yahoogroups.com] On Behalf Of Agestha Hendra
Sent: Wednesday, February 29, 2012 11:26 PM
To: MS_Access_Professionals@yahoogroups.com
Subject: Bls: [MS_AccessPros] Bound Form (Data Entry : Yes) Vs Unbound Form (Insert Into)
Thanx John..
Would you mind give me an example about the Form Error Event that you had told me..?
I think editing record is more complex than inserting data...
Regards
Hendra
________________________________
Dari: John Viescas <john@viescas.com>
Kepada: MS_Access_Professionals@yahoogroups.com
Dikirim: Kamis, 1 Maret 2012 6:25
Judul: RE: [MS_AccessPros] Bound Form (Data Entry : Yes) Vs Unbound Form (Insert Into)
Hendra-
Partly correct. Leave record-level locking turned on.
Here's what will happen when two users try to change the same record:
1) User A will find the record and start to edit it. This sets a timestamp locally.
2) User B will find the same record, edit it, and save. The save sets a timestamp of the time of the save.
3) User A (who went to get a cup of coffee after starting to edit) tries to save.
Result: Access will see that someone else has updated the record since A started to edit. User A will get a warning message with an option to either discard the changes A just tried to make or copy the changes to the clipboard. User A *cannot* overwrite what B just did. You can use the Form_Error event to trap this case and issue a custom message that forces the user to start over.
John Viescas, author
Microsoft Office Access 2010 Inside Out
Microsoft Office Access 2007 Inside Out
Building Microsoft Access Applications
Microsoft Office Access 2003 Inside Out
SQL Queries for Mere Mortals
http://www.viescas.com/
(Kirkland, WA)
-----Original Message-----
From: MS_Access_Professionals@yahoogroups.com [mailto:MS_Access_Professionals@yahoogroups.com] On Behalf Of Agestha Hendra
Sent: Wednesday, February 29, 2012 2:59 PM
To: MS_Access_Professionals@yahoogroups.com
Subject: Bls: [MS_AccessPros] Bound Form (Data Entry : Yes) Vs Unbound Form (Insert Into)
Thanx John...
No Lock setting (is setted on the form ...right?)... is that the same way to unchek "Open Database using record locking"..?
Then if we set all of the form properties to "No Lock", what will happen if more than one users edit the same record in the same time..?..(i can't imagine it)
________________________________
Dari: John Viescas <john@viescas.com>
Kepada: MS_Access_Professionals@yahoogroups.com
Dikirim: Rabu, 29 Februari 2012 23:49
Judul: RE: [MS_AccessPros] Bound Form (Data Entry : Yes) Vs Unbound Form (Insert Into)
Hendra-
Unless you have dozens of simultaneous users, the chance of a "collision" editing records is very very low. As long as you have No Locks set, you should have no problems with bound forms.
Important notes:
1) Users should NOT try to share a database over a wireless connection.
2) Users should share only the "data" database on a server - a database with the tables only. Each user should have his or her own copy of the "code" database (linked tables to the shared data, queries, forms, reports, and code).
John Viescas, author
Microsoft Office Access 2010 Inside Out
Microsoft Office Access 2007 Inside Out
Building Microsoft Access Applications
Microsoft Office Access 2003 Inside Out
SQL Queries for Mere Mortals
http://www.viescas.com/
(Kirkland, WA)
-----Original Message-----
From: MS_Access_Professionals@yahoogroups.com [mailto:MS_Access_Professionals@yahoogroups.com] On Behalf Of Agestha Hendra
Sent: Tuesday, February 28, 2012 5:58 PM
To: MS_Access_Professionals@yahoogroups.com
Subject: Bls: [MS_AccessPros] Bound Form (Data Entry : Yes) Vs Unbound Form (Insert Into)
Thanx John...
Yes..that is what i am thinking...why do we choose the harder way if Access give the simpler way.?..
But the other side i am thinking to about the table's burden (..is the word "burden" right?..sorry if not)..
I mean with the bound form, users are access directly to table at the same time (especially with UPDATE processing)..
so with that opinion i think unbound form is better because it's not access the table directly and no connection to the table happened
until we run the INSERT or UPDATE command.
But in several articles i've read that sometimes Inserting or Updating with codes give slowly processing especially in wireless connection..
Please give me more explanation because i am developing my first multi user application,,so i have to decide the best methods from beginning
Regards
Hendra
________________________________
Dari: John Viescas <john@viescas.com>
Kepada: MS_Access_Professionals@yahoogroups.com
Dikirim: Rabu, 29 Februari 2012 8:26
Judul: RE: [MS_AccessPros] Bound Form (Data Entry : Yes) Vs Unbound Form (Insert Into)
Hendra-
If you use unbound forms, you are putting into code what Access will do for you.
Your application will be much more complex and more time-consuming to build.
There is a small advantage to using unbound forms, but a bound form will provide
very satisfactory results, especially if you set Record Locking to No Locks.
John Viescas, author
Microsoft Office Access 2010 Inside Out
Microsoft Office Access 2007 Inside Out
Building Microsoft Access Applications
Microsoft Office Access 2003 Inside Out
SQL Queries for Mere Mortals
http://www.viescas.com/
(Kirkland, WA)
-----Original Message-----
From: MS_Access_Professionals@yahoogroups.com
[mailto:MS_Access_Professionals@yahoogroups.com] On Behalf Of
agesthahendra@ymail.com
Sent: Tuesday, February 28, 2012 3:30 PM
To: MS_Access_Professionals@yahoogroups.com
Subject: [MS_AccessPros] Bound Form (Data Entry : Yes) Vs Unbound Form (Insert
Into)
Hi All,...
Which is more better in network environment and multi user :
Bound Form (Data Entry : Yes) Or Unbound Form (Insert Into method) ?
Regards
Hendra
------------------------------------
Yahoo! Groups Links
[Non-text portions of this message have been removed]
------------------------------------
Yahoo! Groups Links
[Non-text portions of this message have been removed]
------------------------------------
Yahoo! Groups Links
[Non-text portions of this message have been removed]
------------------------------------
Yahoo! Groups Links
Tidak ada komentar:
Posting Komentar