Dan Elebash
11/21/2002 6:18:00 PM
Unfortunately I don't have many resources in mumps either.
I will check other news groups for tracing, thanks for the
suggestion. But no I don't think this is better posted in
another news group becuaes Access and MSQuery both work
successfully and both enumerate the Tables in the
database, then this is not a mumps issue, although we may
be able to troubleshoot it better with a mumps tracing
tool. Maybe for the next version of odbc.net there should
be a function for listing tables since it is already a
function of the odbc driver it seems like it would be to
difficult to add this. Thanks for your help.
>-----Original Message-----
>Hi Dan,
>
>Yes, we might be able to fix this issue if we were able
to list all the
>tables using ODBC.NET provider. Unfortunately I was not
able to find out
>such a class by examing the help of ODBC.NET. Even we
have this class, it
>could be inaccurate. The fact that none of the SQL
queries generated by
>Access or MSQuery works indicates this. We have two
choices to troubleshoot
>this issue:
>
>1. From client side
>2. From server side
>
>So far what we have tried is all from client side which
is basically some
>black box testing. Should Mumps provide some tools such
as SQL profiler or
>some similar tracing unilities, we will be able to tell
where the problem
>lies in a timely manner, won't we? Say we have the
tracing utility, what we
>need is to compare the trace log of Access and ODBC.NET
and then we will be
>able to tell the difference and do something to work
around this issue.
>Isn't there a better newsgroup that we might request
information about the
>tracing support provided by Mumps DBMS? I don't have
access to the source
>code of ODBC.NET, neither do I have Mumps database at
hand. Thus, checking
>the root cause of this issue from client side is not
efficient in my
>opinion. What do you think of this?
>
>Regards,
>Yan Liu
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>
>.
>