Text 3560, 545 rader
Skriven 2005-04-10 18:39:38 av Rich (1:379/45)
Kommentar till text 3559 av Mike '/m' (1:379/45)
Ärende: Re: wrong data from oracle
==================================
From: "Rich" <@>
This is a multi-part message in MIME format.
------=_NextPart_000_07D5_01C53DFC.A6FA94A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Here you go spinning again. Your complaint below is that the oracle =
ODBC driver doesn't identify the primary index so Access (actually JET) = has
to guess based on what oracle does return. Again, had you actually = read the
KB article without prejudice before you try tossing blame = around you would
have seen that Access (JET) is doing nothing wrong. It = uses the only
information it has.
Yes, it does say that it may select the wrong one because that is =
true if you are trying to infer the primary index from information that = does
not identify the primary index. It does not claim this is an = Access problem.
You even pointed out that this is clearly identified as = by design.
I see you intentionally fail to point out the statement "NOTE: When =
using SQL Server version 6.x, this behavior only occurs if you are using =
non-clustered unique indexes." Maybe you should switch from oracle to a =
better database server like Microsoft SQL Server.
You also fail to point out that this only occurs when linking to an =
ODBC data source and not when accessing ODBC in general.
Finally, you fail to identify why the primary attribute on a linked =
table results in you getting a wrong result. Do you even have a =
justification to blame this behavior or is this typical Mike Miller = behavior
to blame Microsoft or someone else for your own failures?
Rich
"Mike '/m'" <mike@barkto.com> wrote in message =
news:h4hj51pstulobak108hiv6ot7bktf2o3bo@4ax.com...
>If you have complaints about drivers for oracle maybe you should ask =
oracle to provide you with ODBC or OLEDB drivers that you can use with = their
server.
I have no complaints about the ODBC drivers for Oracle. Except for =
the
times we use them with MS Access, the Oracle ODBC drivers have worked
very well. A typical, though failed, attempt on your part to divert =
the
discussion.
The KB articles mention that the problem exists with MS SQL Server =
also.
"When you link a table from an ODBC data source, such as Microsoft SQL
Server or ORACLE, and that table contains more than one unique index,
Microsoft Access may select the wrong index as the primary key."
Note that the KB article says that "Microsoft Access may select the
wrong index..." As much as you would like it to be the case, the
problem has nothing to do with Oracle.
The KB article says it is a MS Access problem.
Nice try, though.
/m
On Sun, 10 Apr 2005 17:14:50 -0700, "Rich" <@> wrote:
> Again you see what you want to see and throw blame where you have =
prejudged. If you have complaints about drivers for oracle maybe you = should
ask oracle to provide you with ODBC or OLEDB drivers that you can = use with
their server.
>
>Rich
>
> "Mike '/m'" <mike@barkto.com> wrote in message =
news:15fj519svfug1ued6e3cbnm6g23jgkd41p@4ax.com...
>
> What I wanted to see was the correct data. What I did not see was =
the
> correct data.=20
>
> Ten years and this bug has not been fixed.
>
> /m
>
>
>
> On Sun, 10 Apr 2005 16:49:14 -0700, "Rich" <@> wrote:
>
> > It just goes to show that you see what you want to see. Had =
you actually read the KB articles someone not prejudiced would see that = that
the reason an unintended index may be selected is that ODBC does = not return
the primary index and that the index must be guessed. = Nowhere does it claim
that wrong data is returned.
> >
> >Rich
> >
> > "Mike '/m'" <mike@barkto.com> wrote in message =
news:6e8j51t7a8r68aktqpe4q5aqhp7h6curd7@4ax.com...
> >
> > btw, for more info:
> >
> > SYMPTOMS
> > When you link (attach) a table from an ODBC data source, such as
> > Microsoft SQL Server or ORACLE, and that table contains more =
than one
> > unique index, Microsoft Access may select the wrong index as the =
primary
> > key.
> >
> > http://support.microsoft.com/default.aspx?scid=3Dkb;EN-US;292047
> >
> > http://support.microsoft.com/default.aspx?scid=3Dkb;EN-US;169777
> >
> > Notice the "This behavior is by design." under the Status =
category of
> > the second link.
> >
> > The existence of this problem, and Microsoft's lack of interest =
in
> > resolving it, was noticed at the CEO and CFO level in my =
company. I
> > suspect that such a cavalier attitude by Microsoft towards the =
validity
> > of the results that MS Access provides will not be A [long-term] =
Good
> > Thing for Microsoft at my company.
> >
> > The question I cannot understand is how can Microsft leave such =
a known
> > and critical bug unfixed for over ten years?
> >
> > /m
> >
> > On Sun, 10 Apr 2005 14:42:55 -0700, Ellen K.
> > <72322.enno.esspeayem.1016@compuserve.com> wrote:
> >
> > >That's pretty gross all right.
> > >
> > >What versions of Access and Oracle?
> > >
> > >I used Access 97 against Oracle 8i at Kaiser without this =
problem, and
> > >know I didn't have it because I would periodically check the =
Oracle data
> > >(retrieved using Access) against the DB2 data on the mainframe
> > >(retrieved interactively) of which it was a clone.
> > >
> > >On Sun, 10 Apr 2005 12:10:42 -0400, Mike '/m' <mike@barkto.com> =
wrote in
> > >message <d5ji511u416i5k7mrgpcdrrk8h8b8ljbtb@4ax.com>:
> > >
> > >>On Sun, 10 Apr 2005 09:51:59 -0400, "Geo" <georger@nls.net> =
wrote:
> > >>
> > >>>"Adam Flinton" <adam@NOSPAM_softfab.com> wrote in message
> > >>>news:4258f782$1@w3.nls.net...
> > >>>
> > >>>> Anyway....the point that was made then was along the lines =
of that's it
> > >>>> for upgrades of office coz quite frankly the users have =
everything they
> > >>>> need now
> > >>>
> > >>>I don't think MS realizes yet what it was that powered that =
growth surge
> > >>>they had in the 90's.
> > >>>
> > >>>[snip]
> > >>>
> > >>>As for Office, we never used it. We went with Works because =
our users simply
> > >>>don't have the skills to require more than that. We've got =
maybe 4 copies of
> > >>>Office but only so we can convert files we get from =
customers, and we
> > >>>convert those to paper <g>.
> > >>>
> > >>>When I order new computers, I order them without hard drives =
as a way to
> > >>>insure that I'm not going to pay for any new copies of an OS =
I'm not going
> > >>>to be using. (well except for laptops)
> > >>
> > >>We use MS Office across the board where I work. =
Unfortunately, MS
> > >>Access is becoming entrenched as well. That is frightening =
because of
> > >>all the problems it has, especially the one we found last =
week. MS
> > >>Access seems to return "unexpected results" when used with an =
ODBC
> > >>connection in some instances. We had production and =
accounting people
> > >>making customer-affecting decisions based upon the bad data =
that MS
> > >>Access was returning. The Software Engineer (one of the most =
senior on
> > >>the team) wrote this in his status report:
> > >>
> > >>=3D=3D=3D
> > >>Worked with [names of users and other Software Engineers =
deleted to
> > >>protect the innocent] to design and implement a work-around =
for a
> > >>stunningly stupid bug in Microsoft Access. When Access is =
used to
> > >>view/update an Oracle table, it sometimes fetches the wrong =
rows. There
> > >>is no error or warning. The bad data could easily be accepted =
and used
> > >>in producing a sample, updating panelist accounts, or whatever =
the user
> > >>is doing.... This bug has existed for over ten years, and is =
documented
> > >>on Microsoft's web site. They apparently have no interest in =
fixing
> > >>it....
> > >>=3D=3D=3D
> > >>
> > >>For that particular Software Engineer to use the phrase =
"stunningly
> > >>stupid bug" (he bolded and italicized it) in his status report =
is
> > >>amazing. He is usually (nearly always) very low-key. *Very* =
low key. =20
> > >>
> > >>
> > >> /m
> > >>
> > >>
> > >>
> > >>
------=_NextPart_000_07D5_01C53DFC.A6FA94A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2604" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2> Here you go spinning =
again. Your=20
complaint below is that the oracle ODBC driver doesn't identify the =
primary=20
index so Access (actually JET) has to guess based on what oracle does=20
return. Again, had you actually read the KB article without =
prejudice=20
before you try tossing blame around you would have seen that Access=20
(JET) is doing nothing wrong. It uses the only information it =
has.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> Yes, it does say that it =
may select=20
the wrong one because that is true if you are trying to infer the = primary
index=20
from information that does not identify the primary index. It does =
not=20
claim this is an Access problem. You even pointed out that = this
is=20
clearly identified as by design.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> I see you intentionally =
fail to point=20
out the statement "NOTE: When using SQL Server version 6.x, this = behavior
only=20
occurs if you are using non-clustered unique indexes." Maybe you =
should=20
switch from oracle to a better database server like Microsoft SQL=20
Server.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> You also fail to point out =
that this=20
only occurs when linking to an ODBC data source and not when accessing = ODBC
in=20
general.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> Finally, you fail to =
identify why the=20
primary attribute on a linked table results in you getting a wrong =
result. =20
Do you even have a justification to blame this behavior or is this = typical
Mike=20
Miller behavior to blame Microsoft or someone else for your own=20
failures?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Rich</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Mike '/m'" <<A =
href=3D"mailto:mike@barkto.com">mike@barkto.com</A>>=20
wrote in message <A=20
=
href=3D"news:h4hj51pstulobak108hiv6ot7bktf2o3bo@4ax.com">news:h4hj51pstul=
obak108hiv6ot7bktf2o3bo@4ax.com</A>...</DIV>>If=20
you have complaints about drivers for oracle maybe you should ask =
oracle to=20
provide you with ODBC or OLEDB drivers that you can use with their=20
server.<BR><BR><BR>I have no complaints about the ODBC drivers for=20
Oracle. Except for the<BR>times we use them with MS Access, the =
Oracle=20
ODBC drivers have worked<BR>very well. A typical, though failed, =
attempt=20
on your part to divert the<BR>discussion.<BR><BR>The KB articles =
mention that=20
the problem exists with MS SQL Server also.<BR>"When you link a table =
from an=20
ODBC data source, such as Microsoft SQL<BR>Server or ORACLE, and that =
table=20
contains more than one unique index,<BR>Microsoft Access may select =
the wrong=20
index as the primary key."<BR><BR>Note that the KB article says that=20
"Microsoft Access may select the<BR>wrong index..." As much as =
you would=20
like it to be the case, the<BR>problem has nothing to do with=20
Oracle.<BR><BR>The KB article says it is a MS Access =
problem.<BR><BR>Nice try,=20
though.<BR><BR> /m<BR><BR><BR><BR>On Sun, 10 Apr 2005 17:14:50 =
-0700,=20
"Rich" <@> wrote:<BR><BR>> Again you see what you =
want to=20
see and throw blame where you have prejudged. If you have =
complaints=20
about drivers for oracle maybe you should ask oracle to provide you =
with ODBC=20
or OLEDB drivers that you can use with their=20
server.<BR>><BR>>Rich<BR>><BR>> "Mike '/m'" <<A=20
href=3D"mailto:mike@barkto.com">mike@barkto.com</A>> wrote in =
message <A=20
=
href=3D"news:15fj519svfug1ued6e3cbnm6g23jgkd41p@4ax.com">news:15fj519svfu=
g1ued6e3cbnm6g23jgkd41p@4ax.com</A>...<BR>><BR>> =20
What I wanted to see was the correct data. What I did not see =
was=20
the<BR>> correct data. <BR>><BR>> Ten years and =
this bug=20
has not been fixed.<BR>><BR>> =20
/m<BR>><BR>><BR>><BR>> On Sun, 10 Apr 2005 16:49:14 =
-0700,=20
"Rich" <@> wrote:<BR>><BR>> > It just =
goes to=20
show that you see what you want to see. Had you actually read =
the KB=20
articles someone not prejudiced would see that that the reason an =
unintended=20
index may be selected is that ODBC does not return the primary index =
and that=20
the index must be guessed. Nowhere does it claim that wrong data =
is=20
returned.<BR>> ><BR>> >Rich<BR>> =20
><BR>> > "Mike '/m'" <<A=20
href=3D"mailto:mike@barkto.com">mike@barkto.com</A>> wrote in =
message <A=20
=
href=3D"news:6e8j51t7a8r68aktqpe4q5aqhp7h6curd7@4ax.com">news:6e8j51t7a8r=
68aktqpe4q5aqhp7h6curd7@4ax.com</A>...<BR>> =20
><BR>> > btw, for more info:<BR>> =20
><BR>> > SYMPTOMS<BR>> > When =
you link=20
(attach) a table from an ODBC data source, such as<BR>> =
> =20
Microsoft SQL Server or ORACLE, and that table contains more than=20
one<BR>> > unique index, Microsoft Access may select =
the=20
wrong index as the primary<BR>> > key.<BR>> =
><BR>> > <A=20
=
href=3D"http://support.microsoft.com/default.aspx?scid=3Dkb;EN-US;292047"=
>http://support.microsoft.com/default.aspx?scid=3Dkb;EN-US;292047</A><BR>=
> =20
><BR>> > <A=20
=
href=3D"http://support.microsoft.com/default.aspx?scid=3Dkb;EN-US;169777"=
>http://support.microsoft.com/default.aspx?scid=3Dkb;EN-US;169777</A><BR>=
> =20
><BR>> > Notice the "This behavior is by design." =
under=20
the Status category of<BR>> > the second =
link.<BR>> =20
><BR>> > The existence of this problem, and =
Microsoft's=20
lack of interest in<BR>> > resolving it, was noticed =
at the=20
CEO and CFO level in my company. I<BR>> > =
suspect that=20
such a cavalier attitude by Microsoft towards the =
validity<BR>> =20
> of the results that MS Access provides will not be A =
[long-term]=20
Good<BR>> > Thing for Microsoft at my =
company.<BR>> =20
><BR>> > The question I cannot understand is how =
can=20
Microsft leave such a known<BR>> > and critical bug =
unfixed=20
for over ten years?<BR>> ><BR>> > =20
/m<BR>> ><BR>> > On Sun, 10 Apr 2005 =
14:42:55=20
-0700, Ellen K.<BR>> > <<A=20
=
href=3D"mailto:72322.enno.esspeayem.1016@compuserve.com">72322.enno.esspe=
ayem.1016@compuserve.com</A>>=20
wrote:<BR>> ><BR>> > >That's pretty =
gross all=20
right.<BR>> > ><BR>> > >What =
versions of Access and Oracle?<BR>> > =
><BR>> =20
> >I used Access 97 against Oracle 8i at Kaiser without =
this=20
problem, and<BR>> > >know I didn't have it =
because I=20
would periodically check the Oracle data<BR>> > =20
>(retrieved using Access) against the DB2 data on the=20
mainframe<BR>> > >(retrieved interactively) of =
which it=20
was a clone.<BR>> > ><BR>> > =
>On=20
Sun, 10 Apr 2005 12:10:42 -0400, Mike '/m' <<A=20
href=3D"mailto:mike@barkto.com">mike@barkto.com</A>> wrote =
in<BR>> =20
> >message <<A=20
=
href=3D"mailto:d5ji511u416i5k7mrgpcdrrk8h8b8ljbtb@4ax.com">d5ji511u416i5k=
7mrgpcdrrk8h8b8ljbtb@4ax.com</A>>:<BR>> =20
> ><BR>> > >>On Sun, 10 Apr 2005 =
09:51:59=20
-0400, "Geo" <<A =
href=3D"mailto:georger@nls.net">georger@nls.net</A>>=20
wrote:<BR>> > >><BR>> > =20
>>>"Adam Flinton" <<A=20
=
href=3D"mailto:adam@NOSPAM_softfab.com">adam@NOSPAM_softfab.com</A>> = wrote
in=20
message<BR>> > =20
>>>news:4258f782$1@w3.nls.net...<BR>> > =20
>>><BR>> > >>>> Anyway....the =
point=20
that was made then was along the lines of that's it<BR>> =
> =20
>>>> for upgrades of office coz quite frankly the users =
have=20
everything they<BR>> > >>>> need=20
now<BR>> > >>><BR>> > =20
>>>I don't think MS realizes yet what it was that powered =
that growth=20
surge<BR>> > >>>they had in the =
90's.<BR>> =20
> >>><BR>> > =20
>>>[snip]<BR>> > >>><BR>> =
> >>>As for Office, we never used it. We went with =
Works=20
because our users simply<BR>> > >>>don't =
have the=20
skills to require more than that. We've got maybe 4 copies =
of<BR>> =20
> >>>Office but only so we can convert files =
we get=20
from customers, and we<BR>> > >>>convert =
those to=20
paper <g>.<BR>> > >>><BR>> =20
> >>>When I order new computers, I order them =
without hard=20
drives as a way to<BR>> > >>>insure that =
I'm not=20
going to pay for any new copies of an OS I'm not going<BR>> =20
> >>>to be using. (well except for =
laptops)<BR>> =20
> >><BR>> > >>We use MS Office =
across=20
the board where I work. Unfortunately, MS<BR>> =
> =20
>>Access is becoming entrenched as well. That is =
frightening=20
because of<BR>> > >>all the problems it has,=20
especially the one we found last week. MS<BR>> =
> =20
>>Access seems to return "unexpected results" when used with an=20
ODBC<BR>> > >>connection in some =
instances. We=20
had production and accounting people<BR>> > =
>>making=20
customer-affecting decisions based upon the bad data that =
MS<BR>> =20
> >>Access was returning. The Software Engineer =
(one of=20
the most senior on<BR>> > >>the team) wrote =
this in=20
his status report:<BR>> > >><BR>> =
> =20
>>=3D=3D=3D<BR>> > >>Worked with [names =
of users and=20
other Software Engineers deleted to<BR>> > =
>>protect=20
the innocent] to design and implement a work-around for =
a<BR>> =20
> >>stunningly stupid bug in Microsoft Access. =
When=20
Access is used to<BR>> > >>view/update an =
Oracle=20
table, it sometimes fetches the wrong rows. There<BR>> =20
> >>is no error or warning. The bad data could =
easily be=20
accepted and used<BR>> > >>in producing a =
sample,=20
updating panelist accounts, or whatever the user<BR>> =
> =20
>>is doing.... This bug has existed for over ten years, and is=20
documented<BR>> > >>on Microsoft's web =
site. =20
They apparently have no interest in fixing<BR>> > =20
>>it....<BR>> > =
>>=3D=3D=3D<BR>> > =20
>><BR>> > >>For that particular Software =
Engineer to use the phrase "stunningly<BR>> > =
>>stupid=20
bug" (he bolded and italicized it) in his status report =
is<BR>> =20
> >>amazing. He is usually (nearly always) very=20
low-key. *Very* low key. <BR>> > =20
>><BR>> > >><BR>> > =
>>=20
/m<BR>> > >><BR>> > =20
>><BR>> > >><BR>> > =20
>><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_07D5_01C53DFC.A6FA94A0--
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|