The universal solution is a real pain, and making the solution work in Access
2000 is a bigger pain because the example code from Microsoft will not behave
right without significant tweaking. Access 97 and 2002 handle it much better.
Basically, what you have to do is trap the BeforeUpdate and Delete events on
the form, grap the data from the bound controls on the form, then perform the
Add, Update, or Delete on the form's RecordsetClone, and Cancel the original
action. Since the recordset action happens in VB code, you can do normal
error trapping to get the error details.
Now, that said, there's a simpler solution - don't allow any add/edit/delete
through a bound form. Use unbound forms instead. This is a paid too, though,
because that means no editing in continuous forms, and that includes
continuous subforms. I suppose you could have continuous forms bound to local
temporary data tables, and copy data back and forth to the server. You'd need
to copy data to the temp data table when it's time to display it in the
subform, and either post changes back to the server after each row update or
use a sequence of of a delete, update, and insert query to post changes back
to the server as a batch. The pain here is that you need to implement your
own Optimistic or Batch Optimistic locking scheme.
On 13 May 2004 07:04:31 -0700,
da*******@web.de (Detlev Ahlgrimm) wrote:
Hi!
I have to use MS-Access2000 as a frontend for an oracle database. And
I dont want to see these ORA-xxxx Popups if an error occures.
So I use something like the following in access (it should work with
sql-server....):
Private Sub Form_Error(DataErr As Integer, Response As Integer)
Dim errX As DAO.Error
If Errors.Count > 1 Then
For Each errX In DAO.Errors
Debug.Print "ODBC Error"
Debug.Print errX.Number
Debug.Print errX.Description
Next errX
end if
End Sub
But I always get Errors.Count=0 :-(
Oracle is version 9.
What is wrong ?
What can I do, to get the oracle-error-number - or better the full
error-description from the popup?
Thanks,
Detlev