ACCESS 95/97 BUG/FEATURE, CAN YOU HELP ? 
Author Message
 ACCESS 95/97 BUG/FEATURE, CAN YOU HELP ?

I have discovered a bug/feature of Access 95/97 which differs from Access 2
and was hoping
someone could help me solve the problem.
When calling DoMenuItem commands in VBA like save record and delete record
it used to be able to
retrieve the ODBC error message back from SQL Server if the operation failed
because of for
example key violation or a trigger failed. The error message could then be
manipulated with
string operations to produce a readable error message for the user.
This worked fine in Access 2 and allowed the application to have no built in
error
checking/trapping as it relied as it should on SQL Server/ODBC providing the
error messages.
This meant any updates to triggers etc. would cause no problem to the Access
application.
There was even A knowledge base article from Microsoft on how to use string
manipulation to
make the error message more readable.
I converted the Access 2 application into Access 95 and found that this was
no longer the case.
All Access 95 would return was 'Error 3146 - ODBC FAILED' when SQL Server
produced an error.
I promptly phoned Microsoft about the problem, once they managed to
re-produce the problem
they too were very surprised and even a little shocked to see that no ODBC
errors could be
retrieved. The problem was closed by Microsoft with no workaround/bug fix
with the answer I quote
'Microsoft is aware of the problem and it will be corrected in Access 97'.
I passed these comments along to my very unhappy client. The Access 95
version of the application was released with loss of functionality. The only
error message I could produce when an ODBC error occurred was a long the
lines of 'An error has occurred because of one of the following:.......'. (A
bit like a Microsoft Error Message!!!!).
I have now performed tests in Access 97 and to my horror have found the same
bug/feature. I have
phoned Microsoft again about the problem and had the same response of shock
and horror once they
reproduced it again. My call is still open at Microsoft but I am starting
the get the impression that no bug fix or workaround is going to be given to
me as they seem to have lost interest in the problem and keep telling me
that its not a bug but a change in the way the product works. In  my opinion
this is rubbish as there would be no point in removing what I believe to be
valuable feature.
There must be other people who have had the same the problem, how did you
solve and/or what did
Microsoft do if anything to help you?

How to re-produce the problem in Access 95/97 - please note that this is a
very crude example:

1. Link to any table on SQL Server which has a primary key.
2. create an autoform based on this table.
3. create a save record button using the control wizard.
4. save the form.
5. open the form and click the new record (>*) navigator button.
6. now enter a new record with a duplicate key.
7. click the save button.
8. note the not very helpful error message.
By going into the code behind the save record button it is clear what is
going on. The same happens with 'DoCmd.DoMenuItem acFormBar, acEditMenu, 7,
, acMenuVer70' when trying to delete a record if for example a trigger
fails.
In Access 2 you could use Error$ to give a short error message 'Error 3146 -
ODBC FAILED' and Error(Err) to give the full ODBC Error message.
 Please also note that if you repeat the above without using the save record
button and instead
use the actual save record from the access menu you will receive a full ODBC
error message.
I would appreciate any help anybody can provide about the problem.
Thanks in advance,



Mon, 22 May 2000 03:00:00 GMT  
 ACCESS 95/97 BUG/FEATURE, CAN YOU HELP ?



Re: using forms and error handling with ODBC

Quote:
> All Access 95 would return was 'Error 3146 - ODBC FAILED' when SQL Server
> produced an error.

You are 100% correct in your findings - it is a "Feature" :-) or
limitation when using bound forms to an ODBC SQL Server DSN, you can
not get more information than the error you reference.  I'm sure
you're aware that in Access 95/97 there is a new errors collection,
that if your recordset is handled through code (DAO/VBA) it is
possible to enumerate the Errors collection to get the additional
information.  Following my signature, there are two articles you may
find
of interest.  

Steve

From the 'Microsoft Jet database Engine Programmers Guide'
Error Objects
As you perform operations by using DAO, errors may occur. Each error
is stored as an Error object in the Errors collection. You can use
information contained in the Error object to determine what caused the
error, and to display meaningful error messages to your users.
It's important to note that as each DAO error occurs, the Errors
collection is cleared of previous errors, and the new Error object is
placed in the Errors collection. There can be several related Error
objects in the collection caused by a single operation.

        From Technet KB:
HOWTO: Get More Information on the ODBC Call Failed Error
PSS ID Number: Q161288
Article last modified on 07-14-1997
PSS database name: VBWIN

5.00

WINDOWS

======================================================================
---------------------------------------------------------------------
The information in this article applies to:

 - Microsoft Visual Basic Professional and Enterprise Editions,
   for Windows, version 5.0
---------------------------------------------------------------------

SUMMARY
=======

This article describes how to get more information on the ODBC Call
Failed
error. When errors occur using ODBC databases, Visual Basic will
provide an
"ODBC Call Failed" error message. This generic error message provides
no
specific detail so you must cycle through the Errors collection to get
additional information. Below is a code sample that shows the
difference in
behavior.

MORE INFORMATION
================

The DBEngine has an Errors collection that can be manipulated by the
FOR-
EACH construct. The JET Engine can store multiple errors in the
DBEngine
Errors collection. In Visual Basic 3.0, it was possible to parse the
string
using the routine shown on Page 175 of the Visual Basic 4.0
Professional
Features Book under the "Guide to Data Access Objects" section. The #
symbol was used to separate the "ODBC Call Failed" message from the
detailed ODBC description in Visual Basic 3.0. However, this is not
necessary under Visual Basic versions 4.0 and 5.0.

For the example below, a two-field table called MyTable has been set
up on
an ODBC Source and a primary key set on the ID Field. Two records have
been
added as below:

   Field      ID      Description
   ===============================
   Record 1    1      Hello
   Record 2    2      World

The code below will generate an error by trying to add a record with a
duplicate primary key value to test the code:

1. Start a new Standard EXE project. Form1 is added by default.

2. Add a CommandButton to Form1.

3. Add the following code to the General Declarations section of
Form1:

      Option Explicit

      Private Sub Command1_Click()
        Dim db As Database
        Dim rs As Recordset
        On Error GoTo trap
        Set db = OpenDatabase("")
        Set rs = db.OpenRecordset("Select * from MyTable")
        rs.AddNew
          rs.Fields(0).Value = 2
        rs.Update
        Exit Sub
      trap:
        MsgBox Errors.Count
        MsgBox Err.Number & " " & Err.Description
      End Sub

4. Press the F5 key to run the project. Click on the CommandButton and
you
   should receive error 3146, "ODBC Call Failed." Although the Error
count
   is greater than one, only one message will be displayed.

5. Remove the code from within the error trap and replace it with one
   of the following error handlers:

      ' DAO Error Handler
      Dim MyError As Error
      MsgBox Errors.Count
      For Each MyError In DBEngine.Errors
        With MyError
          MsgBox .Number & " " & .Description
        End With
      Next MyError

      ' RDO Error Handler
      Dim MyError As rdoError
      MsgBox rdoErrors.Count
      For Each MyError In rdoEngine.rdoErrors
        With MyError
          MsgBox .Number & " " & .Description
        End With
      Next MyError

6. Press the F5 key to run the project. You should see a detailed
message
   and then the 3146 Error for "ODBC Call Failed."

REFERENCES
==========

Visual Basic 4.0 Professional Features, Chapter 9 of the "Guide to
Data
Access Object"

Jet Database Engine Programmers Guide, pages 425-427

For additional information, please see the following article in the
Microsoft Knowledge Base:

   ARTICLE-ID: Q120763
   TITLE     : How to Retrieve Info from RAISERROR Function in SQL
               Server DB

Additional query words: errors Collection
======================================================================
Keywords            : kbusage vb5all vb5howto VBKBError VBKBODBC
kbhowto
Version             : 5.00
Platform            : WINDOWS
Issue type          : kbhowto
============================================================================
=
Copyright Microsoft Corporation 1997.



Wed, 24 May 2000 03:00:00 GMT  
 ACCESS 95/97 BUG/FEATURE, CAN YOU HELP ?

Quote:



>Re: using forms and error handling with ODBC
>> All Access 95 would return was 'Error 3146 - ODBC FAILED' when SQL Server
>> produced an error.

>You are 100% correct in your findings - it is a "Feature" :-) or
>limitation when using bound forms to an ODBC SQL Server DSN, you can
>not get more information than the error you reference.  I'm sure
>you're aware that in Access 95/97 there is a new errors collection,
>that if your recordset is handled through code (DAO/VBA) it is
>possible to enumerate the Errors collection to get the additional
>information.  Following my signature, there are two articles you may
>find
>of interest.

>Steve

Thanks for the reply steve.

I fully understand that you can get full ODBC error messages by using code
and have done it before. I think
that using that method in Access makes access itself redundant as you then
have to duplicate in code lots of functionality that Access provides for you
and its that functionality that makes Access such a good RAD tool. I would
then bin Access and use VB if I was going to use this method.

I just can not understand why someone would want to remove the ability to
retrieve full ODBC error messages
when using bound forms and hence think that it is a bug, an omission when
porting Access 2 over to the 32 Bit platform, I only wish that Microsoft
would own up and stop the bullshit they keep giving me and admit it and give
me a workaround or even having the problem resolved in Access 98 (Assuming
Access 98 come out in 1998 and not the year 2001 !!! :) ) would be enough to
calm down my very upset customer and restore me and my customers faith in
Microsoft.

Dan




Thu, 25 May 2000 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Access 95 and (Excel 97 and Excel 95)

2. convert Access 2 in Access 95 and Access 97

3. Determining file Version via VB(word 95, 97, Excel 95 97)

4. help: read 95/98 registry with Access 97

5. HELP WANT (818) area, access 95&97/VBA/ActiveX Controls

6. Need help with VB4 and access 95 and 97

7. Converting VB code modules in Access 95 to Access 97

8. Access 95 and Access 97 Compacting Problems

9. TransferDatabase method from Access 95 mdb to Access 97 mdb

10. Access 95 ---> Access 97

11. ACCESS 95 & ACCESS 97

 

 
Powered by phpBB® Forum Software