A bug in MS Access

[Guest]

Hi TC,
You made confusion in me and i thought you were right. Now it seems as a
bug in MS Access. And also a bug in ADO.Net because of the bug in MS Access.
I used OleDbCommand, OleDbCommandParameter, OleDbConnection Objects and
executed the delete query with a wrong column Name. No exception thrown and
all rows got deleted. The case here can be, it taken the value I given for
the non existing column name and deleted all the rows from the table. So, it
seems a valid bug. The problem is in MS Access right, not in Jet. Thanks Tim
for the information

Thanks and regards,
Rajeev

 

[TC]

Sorry Rajeev, I don't know ADO or ADO.Net. Maybe if you post the full
code, someone else can comment.

HTH,
TC

 

[Guest]

Hi All,
I was getting wrong result in MS Access with ADO.Net 2002 version. As I am
getting the proper Exception in ADO.Net 2003, I am closing this thread.
So, I am concluding that there should not be any prompting for Invalid
column name in the delete query as it gives wrong impression in MS Access.
Hope related persons will take care of this in future version of MS Access.
Thanks to everybody who replied for this thread and made thid meaning ful.

Thanks and Regards,
Rajeevan

 

[Tim Ferguson]

You made confusion in me and i thought you were right. Now it seems
as a
bug in MS Access. And also a bug in ADO.Net because of the bug in MS
Access.

THERE IS NO BUG -- all this is expected behaviour according to the way
that Access works; it's well documented in the Help, and in just about
every manual that has ever been written. It is behaviour turning up in a
slightly unusual and unexpected situation, but that does not alter the
fact that it's a _developer_ problem not a Microsoft one (and you don't
catch me saying that very often!).

Scenario one: a query like this

SELECT Something FROM Somewhere WHERE Location = [Enter
location here:]"

Bog-standard parameter query: if you are using VBA, then the DB Engine
will throw an error because the [Enter location here:] parameter was not
declared; while the Access GUI will intercept it and raise an input box.
This is normal expected behaviour and lots of people would be moaning if
it were any other way.

Scenario two: a query like this

SELECT Something FROM Somewhere WHERE [non existent field] = 10;

is actually exactly the same. Until Microsoft actually release their
Telepathy Extensions, Access has No Way Of Knowing that the [non existent
field] is not an undeclared parameter. So it reacts in the normal, time-
honoured, documented and expected way -- see above. No bug. No problem.

In this particular situation, it is the developer's responsibility to
ensure that he or she is releasing properly debugged code with (at the
very least!) no mis-spellings in the SQL. There is no excuse -- the
problem you are reporting here is one of lazy programming and inadequate
testing. Just this once, you cannot shift the blame onto Microsoft; you
have hour own house to get in order.

Hope that helps


Tim F

 

[Guest]

Hi Tim,

Thanks for the clarification. Actually I was not blaming Microsoft for
developer's fault. This thing happened long back and the code was written by
my friend and I was the person who corrected the error. I just want to get a
clarification regarding this. Because of this nothing happened, or caused any
damage to anybody. I did'nt found any forum to discuss this. So, I came here
to get a proper reply. Still I got Confused of some answer and it was
clarified by you.

I thought it was a valid suggestion to request Microsoft to change this
behavior in the future versions of Access. I think you misunderstood what I
meant.
I cannot blame Microsoft as I am working in and satisfied with Microsoft
technologies.

Thanks and regards,
-Rajeev

You made confusion in me and i thought you were right. Now it seems
as a
bug in MS Access. And also a bug in ADO.Net because of the bug in MS
Access.

THERE IS NO BUG -- all this is expected behaviour according to the way
that Access works; it's well documented in the Help, and in just about
every manual that has ever been written. It is behaviour turning up in a
slightly unusual and unexpected situation, but that does not alter the
fact that it's a _developer_ problem not a Microsoft one (and you don't
catch me saying that very often!).

Scenario one: a query like this

SELECT Something FROM Somewhere WHERE Location = [Enter
location here:]"

Bog-standard parameter query: if you are using VBA, then the DB Engine
will throw an error because the [Enter location here:] parameter was not
declared; while the Access GUI will intercept it and raise an input box.
This is normal expected behaviour and lots of people would be moaning if
it were any other way.

Scenario two: a query like this

SELECT Something FROM Somewhere WHERE [non existent field] = 10;

is actually exactly the same. Until Microsoft actually release their
Telepathy Extensions, Access has No Way Of Knowing that the [non existent
field] is not an undeclared parameter. So it reacts in the normal, time-
honoured, documented and expected way -- see above. No bug. No problem.

In this particular situation, it is the developer's responsibility to
ensure that he or she is releasing properly debugged code with (at the
very least!) no mis-spellings in the SQL. There is no excuse -- the
problem you are reporting here is one of lazy programming and inadequate
testing. Just this once, you cannot shift the blame onto Microsoft; you
have hour own house to get in order.

Hope that helps


Tim F