Text 3558, 375 rader
Skriven 2005-04-10 17:14:50 av Rich (1:379/45)
Kommentar till text 3557 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_07C1_01C53DF0.CD9F4620
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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_07C1_01C53DF0.CD9F4620
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> Again you see what you =
want to see and=20
throw blame where you have prejudged. If you have complaints about =
drivers=20
for oracle maybe you should ask oracle to provide you with ODBC or OLEDB =
drivers=20
that you can use with their server.</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:15fj519svfug1ued6e3cbnm6g23jgkd41p@4ax.com">news:15fj519svfu=
g1ued6e3cbnm6g23jgkd41p@4ax.com</A>...</DIV><BR>What=20
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 has not been=20
fixed.<BR><BR> /m<BR><BR><BR><BR>On Sun, 10 Apr 2005 16:49:14 =
-0700,=20
"Rich" <@> wrote:<BR><BR>> It just goes to show =
that you=20
see what you want to see. Had you actually read the KB articles =
someone=20
not prejudiced would see that that the reason an unintended index may =
be=20
selected is that ODBC does not return the primary index and that the =
index=20
must be guessed. Nowhere does it claim that wrong data is=20
returned.<BR>><BR>>Rich<BR>><BR>> "Mike '/m'" <<A =
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>><BR>> =20
btw, for more info:<BR>><BR>> SYMPTOMS<BR>> When =
you link=20
(attach) a table from an ODBC data source, such as<BR>> =
Microsoft SQL=20
Server or ORACLE, and that table contains more than one<BR>> =
unique=20
index, Microsoft Access may select the wrong index as the=20
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>=
><BR>> =20
<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>=
><BR>> =20
Notice the "This behavior is by design." under the Status category=20
of<BR>> the second link.<BR>><BR>> The existence =
of this=20
problem, and Microsoft's lack of interest in<BR>> resolving =
it, was=20
noticed at the CEO and CFO level in my company. I<BR>> =
suspect=20
that 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>><BR>> =20
The question I cannot understand is how can Microsft leave such a=20
known<BR>> and critical bug unfixed for over ten=20
years?<BR>><BR>> /m<BR>><BR>> On Sun, 10 =
Apr=20
2005 14:42:55 -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 =
right.<BR>> =20
><BR>> >What versions of Access and =
Oracle?<BR>> =20
><BR>> >I used Access 97 against Oracle 8i at Kaiser =
without=20
this problem, and<BR>> >know I didn't have it because I =
would=20
periodically check the Oracle data<BR>> >(retrieved using =
Access)=20
against the DB2 data on the mainframe<BR>> >(retrieved=20
interactively) of which it was a clone.<BR>> =
><BR>> =20
>On 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 -0400, "Geo" =
<<A=20
href=3D"mailto:georger@nls.net">georger@nls.net</A>> =
wrote:<BR>> =20
>><BR>> >>>"Adam Flinton" <<A=20
=
href=3D"mailto:adam@NOSPAM_softfab.com">adam@NOSPAM_softfab.com</A>> = wrote
in=20
message<BR>> =
>>>news:4258f782$1@w3.nls.net...<BR>> =20
>>><BR>> >>>> Anyway....the point that =
was made=20
then was along the lines of that's it<BR>> >>>> =
for=20
upgrades of office coz quite frankly the users have everything=20
they<BR>> >>>> need now<BR>> =20
>>><BR>> >>>I don't think MS realizes yet =
what it=20
was that powered that growth surge<BR>> >>>they had =
in the=20
90's.<BR>> >>><BR>> =20
>>>[snip]<BR>> >>><BR>> =
>>>As for=20
Office, we never used it. We went with Works because our users=20
simply<BR>> >>>don't have the skills to require more =
than=20
that. We've got maybe 4 copies of<BR>> =
>>>Office but=20
only so we can convert files we get from customers, and =
we<BR>> =20
>>>convert those to paper <g>.<BR>> =20
>>><BR>> >>>When I order new computers, I =
order=20
them without hard drives as a way to<BR>> >>>insure =
that I'm=20
not 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 the board where =
I=20
work. Unfortunately, MS<BR>> >>Access is becoming =
entrenched as well. That is frightening because of<BR>> =
>>all the problems it has, especially the one we found last =
week. =20
MS<BR>> >>Access seems to return "unexpected results" =
when used=20
with an ODBC<BR>> >>connection in some instances. =
We had=20
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 the =
most=20
senior on<BR>> >>the team) wrote this in his status=20
report:<BR>> >><BR>> =
>>=3D=3D=3D<BR>> =20
>>Worked with [names of users and other Software Engineers =
deleted=20
to<BR>> >>protect the innocent] to design and implement =
a=20
work-around for a<BR>> >>stunningly stupid bug in =
Microsoft=20
Access. When Access is used to<BR>> >>view/update =
an=20
Oracle table, it sometimes fetches the wrong rows. =
There<BR>> =20
>>is no error or warning. The bad data could easily be =
accepted=20
and used<BR>> >>in producing a sample, updating =
panelist=20
accounts, or whatever the user<BR>> >>is doing.... This =
bug has=20
existed for over ten years, and is documented<BR>> >>on =
Microsoft's web site. They apparently have no interest in=20
fixing<BR>> >>it....<BR>> =
>>=3D=3D=3D<BR>> =20
>><BR>> >>For that particular Software Engineer =
to use=20
the phrase "stunningly<BR>> >>stupid bug" (he bolded =
and=20
italicized it) in his status report is<BR>> =
>>amazing. He=20
is usually (nearly always) very low-key. *Very* low key. =20
<BR>> >><BR>> >><BR>> >>=20
/m<BR>> >><BR>> >><BR>> =20
>><BR>> >><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_07C1_01C53DF0.CD9F4620--
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|