Text 5373, 405 rader
Skriven 2005-06-24 19:30:26 av Rich (1:379/45)
Kommentar till text 5370 av Mike '/m' (1:379/45)
Ärende: Re: oracle returning wrong data to mike, again
======================================================
From: "Rich" <@>
This is a multi-part message in MIME format.
------=_NextPart_000_0045_01C578F3.2CA9D1C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
The diversion is yours. You are the one that claimed that oracle =
returned the wrong data. That you claim that Access asked for the wrong = data
is exactly what I would expect of you.
As for reading the KB fully, it is clear that you have not. Aside =
from having the first unique index perceived as the key labeled = "primary" in
the UI, so what? If you were getting wrong results from = oracle, what the
Access UI labels the "primary" key makes no difference.
What does make a difference is your inability to identify what was =
wrong. You assert that oracle returned correct data? If you honestly =
checked this and checked the data returned when you got the wrong = results,
what was different? How does the index used by the oracle = server, regardless
which one, cause the wrong data to be returned?
Rich
"Mike '/m'" <mike@barkto.com> wrote in message =
news:hvapb1hggtcokn58lnpr0ktg4432u6bt01@4ax.com...
Your diversionary tactics are quite humorous. Oracle gave back the =
data
that was asked for by MS Access, but MS Access was asking for the =
wrong
data because it was using the wrong index. If you had read the MS KB
article fully, you would have known that is the problem. But, in
typical Microsoft fashion, you seem to prefer to divert attention =
awway
from the Microsoft problem.
MS Access is now returning the correct data after we renamed the =
primary
indices in Oracle to come first in alphabetical order, per the MS KB
article. This design flaw in ODBC is just another little detail that
makes it easier to justify not moving more of our serves to MS =
Windows.
/m
On Fri, 24 Jun 2005 16:17:31 -0700, "Rich" <@> wrote:
> No, the ODBC SQLStatistics API does not identify the primary index =
just as I stated earlier. The level 2 API you suggest SQLPrimaryKeys is =
buggy.
>
> If oracle is returning the correct data why were you complaining =
that you get the wrong data? Why are you so steadfast in refusing to = support
your assertion with anything more than repeated assertion?
>
>Rich
>
> "Mike '/m'" <mike@barkto.com> wrote in message =
news:th0pb1lvtlskallhmns5ji6ns2cn5k1rn9@4ax.com...
>
> You're really not suggesting that MS Access uses the wrong API =
because
> it is buggy? That's hilarious.
>
> Previously you said, "The ODBC API doesn't identify the primary =
index."
> Now you post saying that the ODBC API does identify the Primary =
index.
> You really should stick to one story.
>
> Additionally, MS SQL server also has the same problem, (unless of
> course, the KB article was wrong, as you say about the security
> article). So it is not a matter of Oracle returning bad data. =
Once we
> worked around the ODBC API problem, Oracle is returning precisely =
the
> correct data.
>
> /m
>
>
> On Fri, 24 Jun 2005 00:19:11 -0700, "Rich" <@> wrote:
>
> > Nice spin on own your earlier attempts to lay blame for you =
getting bad results from your oracle database. We can ignore that which =
index if any is the "primary" index is not relevant despite you trying = to
assert a connection. What you fail to mention about that thread is = that
beside your assertion and your repeated attempts to spread blame = elsewhere
you never identified what was wrong, what you changed to get = the correct
results from oracle, and some evidence to support your = disparaging
statements. Do you really want to discuss why your make = disparaging remarks
but make a diversion when asked to back up your = claims?
> >
> > As for your new attempts to question why SQLPrimaryKeys may not =
be used, a simple answer is that it is often buggy, its level 2 not = level 1,
and other than UI to display a linked table's definition it = doesn't matter.
See =
http://support.borland.com/entry.jspa?externalID=3D1623&categoryID=3D333 = for
an example of it returning incorrect results for oracle. See =
http://community.borland.com/article/0,1410,25091,0.html for an example = of it
returning incorrect results for interbase. You probably should = avoid calling
SQLPrimaryKeys for mysql too. See = http://bugs.mysql.com/bug.php?id=3D3797.
> >
> >Rich
> >
> > "Mike '/m'" <mike@barkto.com> wrote in message =
news:v4dmb15fampi1025tim8ssifm43kqusg1f@4ax.com...
> > On Thu, 23 Jun 2005 06:24:23 -0400, "Geo" <georger@nls.net> =
wrote:
> >
> > >"John Cuccia" <jcuccia@bigfoot.com> wrote in message
> > >news:u1djb1dkjvvqk9j4clgajl86tuhtsott6j@4ax.com...
> > >> Well, I've read the thread between you and Geo and I am =
confused.
> > >>
> > >> Would you mind explaining again, please?
> > >
> > >He's worried that if he explains in plain terms that it might =
be news (I
> > >would think deliberately inaccurate security bulletins would be =
a news
> > >worthy item) and he might get quoted and then he might get in =
trouble for
> > >telling the truth when it's pretty obvious that MS isn't =
interested in the
> > >truth being known.
> > >
> > >I don't want Rich to ever get in trouble for talking to us, do =
you?
> >
> > I'd never want anyone to get into trouble for what is posted =
here. =20
> >
> > I am just not convinced that is Rich's reason for being so =
obstinate
> > here. He was similarly obstinate when I brought up the problem =
with MS
> > Access returning the wrong data via an ODBC connection. He even =
said
> > that the ODBC API doesn't identify the primary index, even =
though there
> > is an SQLPrimaryKeys ODBC call which does return the primary =
key. I
> > even posted a link to that ODBC call on Microsoft's site. Why =
doesn't
> > MS Access use it, instead of posting a "working as designed" KB =
article.
> >
> > When I tried to get clarification on that thread, all I received =
was the
> > similar barrage of ad hominem insults that I have been receiving =
here on
> > the buffer overrun topic.
> >
> > On the other hand, if Rich does not want to have to answer =
questions in
> > threads because he may fear being quoted, as you say, then maybe =
it
> > would be better for him to just stay out of the thread or not =
answer the
> > questions, instead of throwing insults. =20
> >
> > /m
------=_NextPart_000_0045_01C578F3.2CA9D1C0
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.2668" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2> The diversion is =
yours. You are=20
the one that claimed that oracle returned the wrong data. That you =
claim=20
that Access asked for the wrong data is exactly what I would expect of=20
you.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> As for reading the KB =
fully, it is=20
clear that you have not. Aside from having the first unique index=20
perceived as the key labeled "primary" in the UI, so what? If you =
were=20
getting wrong results from oracle, what the Access UI labels the = "primary"
key=20
makes no difference.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2> What does make a =
difference is your=20
inability to identify what was wrong. You assert that oracle =
returned=20
correct data? If you honestly checked this and checked the data =
returned=20
when you got the wrong results, what was different? How does the =
index=20
used by the oracle server, regardless which one, cause the wrong data to =
be=20
returned?</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>
<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:hvapb1hggtcokn58lnpr0ktg4432u6bt01@4ax.com">news:hvapb1hggtc=
okn58lnpr0ktg4432u6bt01@4ax.com</A>...</DIV>Your=20
diversionary tactics are quite humorous. Oracle gave back the=20
data<BR>that was asked for by MS Access, but MS Access was asking for =
the=20
wrong<BR>data because it was using the wrong index. If you =
had=20
read the MS KB<BR>article fully, you would have known that is the=20
problem. But, in<BR>typical Microsoft fashion, you seem to =
prefer to=20
divert attention awway<BR>from the Microsoft problem.<BR><BR>MS Access =
is now=20
returning the correct data after we renamed the primary<BR>indices in =
Oracle=20
to come first in alphabetical order, per the MS KB<BR>article. =
This=20
design flaw in ODBC is just another little detail that<BR>makes it =
easier to=20
justify not moving more of our serves to MS Windows.<BR><BR><BR> =
/m<BR><BR><BR><BR><BR><BR><BR>On Fri, 24 Jun 2005 16:17:31 -0700, =
"Rich"=20
<@> wrote:<BR><BR>> No, the ODBC SQLStatistics =
API does=20
not identify the primary index just as I stated earlier. The =
level 2 API=20
you suggest SQLPrimaryKeys is buggy.<BR>><BR>> If =
oracle is=20
returning the correct data why were you complaining that you get the =
wrong=20
data? Why are you so steadfast in refusing to support your =
assertion=20
with anything more than repeated=20
assertion?<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:th0pb1lvtlskallhmns5ji6ns2cn5k1rn9@4ax.com">news:th0pb1lvtls=
kallhmns5ji6ns2cn5k1rn9@4ax.com</A>...<BR>><BR>> =20
You're really not suggesting that MS Access uses the wrong API=20
because<BR>> it is buggy? That's=20
hilarious.<BR>><BR>> Previously you said, "The ODBC API =
doesn't=20
identify the primary index."<BR>> Now you post saying that =
the ODBC=20
API does identify the Primary index.<BR>> You really should =
stick to=20
one story.<BR>><BR>> Additionally, MS SQL server also has =
the same=20
problem, (unless of<BR>> course, the KB article was wrong, as =
you say=20
about the security<BR>> article). So it is not a =
matter=20
of Oracle returning bad data. Once we<BR>> worked =
around the=20
ODBC API problem, Oracle is returning precisely the<BR>> =
correct=20
data.<BR>><BR>> /m<BR>><BR>><BR>> On =
Fri, 24=20
Jun 2005 00:19:11 -0700, "Rich" <@> wrote:<BR>><BR>> =
> Nice spin on own your earlier attempts to lay blame =
for you=20
getting bad results from your oracle database. We can ignore =
that which=20
index if any is the "primary" index is not relevant despite you trying =
to=20
assert a connection. What you fail to mention about that thread =
is that=20
beside your assertion and your repeated attempts to spread blame =
elsewhere you=20
never identified what was wrong, what you changed to get the correct =
results=20
from oracle, and some evidence to support your disparaging =
statements. =20
Do you really want to discuss why your make disparaging remarks but =
make a=20
diversion when asked to back up your claims?<BR>> =
><BR>> =20
> As for your new attempts to question why =
SQLPrimaryKeys may=20
not be used, a simple answer is that it is often buggy, its level 2 =
not level=20
1, and other than UI to display a linked table's definition it doesn't =
matter. See <A=20
=
href=3D"http://support.borland.com/entry.jspa?externalID=3D1623&categ=
oryID=3D333">http://support.borland.com/entry.jspa?externalID=3D1623&=
categoryID=3D333</A>=20
for an example of it returning incorrect results for oracle. See =
<A=20
=
href=3D"http://community.borland.com/article/0,1410,25091,0.html">http://=
community.borland.com/article/0,1410,25091,0.html</A>=20
for an example of it returning incorrect results for interbase. =
You=20
probably should avoid calling SQLPrimaryKeys for mysql too. See =
<A=20
=
href=3D"http://bugs.mysql.com/bug.php?id=3D3797">http://bugs.mysql.com/bu=
g.php?id=3D3797</A>.<BR>> =20
><BR>> >Rich<BR>> ><BR>> =
> "Mike=20
'/m'" <<A href=3D"mailto:mike@barkto.com">mike@barkto.com</A>> =
wrote in=20
message <A=20
=
href=3D"news:v4dmb15fampi1025tim8ssifm43kqusg1f@4ax.com">news:v4dmb15famp=
i1025tim8ssifm43kqusg1f@4ax.com</A>...<BR>> =20
> On Thu, 23 Jun 2005 06:24:23 -0400, "Geo" <<A=20
href=3D"mailto:georger@nls.net">georger@nls.net</A>> =
wrote:<BR>> =20
><BR>> > >"John Cuccia" <<A=20
href=3D"mailto:jcuccia@bigfoot.com">jcuccia@bigfoot.com</A>> wrote =
in=20
message<BR>> > =20
>news:u1djb1dkjvvqk9j4clgajl86tuhtsott6j@4ax.com...<BR>> =20
> >> Well, I've read the thread between you and Geo and =
I am=20
confused.<BR>> > >><BR>> > =
>>=20
Would you mind explaining again, please?<BR>> > =20
><BR>> > >He's worried that if he explains in =
plain=20
terms that it might be news (I<BR>> > >would =
think=20
deliberately inaccurate security bulletins would be a =
news<BR>> =20
> >worthy item) and he might get quoted and then he might =
get in=20
trouble for<BR>> > >telling the truth when it's =
pretty=20
obvious that MS isn't interested in the<BR>> > =
>truth=20
being known.<BR>> > ><BR>> > =
>I=20
don't want Rich to ever get in trouble for talking to us, do=20
you?<BR>> ><BR>> > I'd never want anyone =
to get=20
into trouble for what is posted here. <BR>> =
><BR>> =20
> I am just not convinced that is Rich's reason for being so=20
obstinate<BR>> > here. He was similarly =
obstinate when=20
I brought up the problem with MS<BR>> > Access =
returning the=20
wrong data via an ODBC connection. He even said<BR>> =
> =20
that the ODBC API doesn't identify the primary index, even though=20
there<BR>> > is an SQLPrimaryKeys ODBC call which =
does=20
return the primary key. I<BR>> > even posted a =
link to=20
that ODBC call on Microsoft's site. Why doesn't<BR>> =
> =20
MS Access use it, instead of posting a "working as designed" KB=20
article.<BR>> ><BR>> > When I tried to =
get=20
clarification on that thread, all I received was the<BR>> =
> =20
similar barrage of ad hominem insults that I have been receiving here=20
on<BR>> > the buffer overrun topic.<BR>> =20
><BR>> > On the other hand, if Rich does not want =
to have=20
to answer questions in<BR>> > threads because he may =
fear=20
being quoted, as you say, then maybe it<BR>> > would =
be=20
better for him to just stay out of the thread or not answer =
the<BR>> =20
> questions, instead of throwing insults. =
<BR>> =20
><BR>> > =
/m<BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0045_01C578F3.2CA9D1C0--
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|