SqlClient Severity Error Problem

[BuddyHome]

I posted an a problem in the newsgroup on 26 Feb 2004 here is the link
http://groups.google.com/groups?hl=...erity&hl=en&lr=&ie=UTF-8&oe=UTF-8&sa=N&tab=wg

Microsoft has confirmed this is a bug and they have fixed it in Whidbey but
they refuse to fix it in Framework 1.1, I just don't understand why?

 

[William \(Bill\) Vaughn]

I don't characterize this behavior as a "bug". It is certainly a limitation
for some applications, but we've managed to deal with this reality for over
decade.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

 

[BuddyHome]

I disagree because Microsoft SqlClient Dev Team has clearly said that this
is a bug.

They have omited to it and have fixed it in Whidbey. Odbc.net works
correctly.

Thanks,

 

[BuddyHome]

Hi William,

Can you explain how you have dealt with in the last decade without rewriting
thousands of line of code.

Thanks,

 

[William \(Bill\) Vaughn]

It has always worked this way. I (and the people I work with) have always
written their applications knowing this behavior was there. It's like
driving a car with a stick shift--it requires a knowledge of how the clutch
works. It's not a bug.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

 

[Kevin Yu [MSFT]]

Thanks for Bill's quick response.

Hi BuddyHome,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you would like to confirm why the know
issue in ExecuteReader isn't going to be fixed in .NET framework 1.1. If
there is any misunderstanding, please feel free to let me know.

Based on the discussion above, I assume that you have contacted Microsoft
PSS, and the PSS has confirmed that this is a bug. If you have opened a
case, could you please give us the case ID, so that we can contact the
support professional and the DEV team? They must have reasons for why the
problem isn't going to be fixed. You can also call or email to PSS to
reopen the case, and I think they will give you an answer.

If anything is unclear, please feel free to reply to the post.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

 

[Angel Saenz-Badillos[MS]]

BuddyHome,
I understand your frustration and I am sorry to say that I really don't know
of a good workaround. I want to make sure that you understand that we did
not make this decision lightly and explain the problem we are facing.

SqlClient Dev Team has clearly said that this is a bug.

Not quite. The problem is that it is not a bug, you are getting an exception
in your query and we throw an exception. This is not a bug since it was the
way SqlClient was designed to work, the fact that ODBC works in a different
way is immaterial (if unfortunate) to this discussion. This is behavior that
everybody that is currently using SqlClient may be depending on, if we
suddenly stop throwing an exception here applications that are currently
working may break. The bottom line is that we cannot modify the existing
behavior of SqlClient without risking breaking somebody, we can't do it on a
QFE and we can't do it for Whidbey.

We do realize that for many scenarios it is critical to be able to get to
the data retrieved after the exception, we need to be able to do this
without breaking existing applications. In the whidbey alpha we have made
API changes to ado.net that will allow you to get to this data.
Unfortunately it is not possible to make API changes as part of a QFE
release so we don't have any way of backporting this fix back to Everett.