Tillbaka till svenska Fidonet
English   Information   Debug  
OS2BBS   0/787
OS2DOSBBS   0/580
OS2HW   0/42
OS2INET   0/37
OS2LAN   0/134
OS2PROG   0/36
OS2REXX   0/113
OS2USER-L   207
OS2   0/4786
OSDEBATE   0/18996
PASCAL   0/490
PERL   0/457
PHP   0/45
POINTS   0/405
POLITICS   0/29554
POL_INC   0/14731
PSION   103
R20_ADMIN   1121
R20_AMATORRADIO   0/2
R20_BEST_OF_FIDONET   13
R20_CHAT   0/893
R20_DEPP   0/3
R20_DEV   399
R20_ECHO2   1379
R20_ECHOPRES   0/35
R20_ESTAT   0/719
R20_FIDONETPROG...
...RAM.MYPOINT
  0/2
R20_FIDONETPROGRAM   0/22
R20_FIDONET   0/248
R20_FILEFIND   0/24
R20_FILEFOUND   0/22
R20_HIFI   0/3
R20_INFO2   3221
R20_INTERNET   0/12940
R20_INTRESSE   0/60
R20_INTR_KOM   0/99
R20_KANDIDAT.CHAT   42
R20_KANDIDAT   28
R20_KOM_DEV   112
R20_KONTROLL   0/13273
R20_KORSET   0/18
R20_LOKALTRAFIK   0/24
R20_MODERATOR   0/1852
R20_NC   76
R20_NET200   245
R20_NETWORK.OTH...
...ERNETS
  0/13
R20_OPERATIVSYS...
...TEM.LINUX
  0/44
R20_PROGRAMVAROR   0/1
R20_REC2NEC   534
R20_SFOSM   0/340
R20_SF   0/108
R20_SPRAK.ENGLISH   0/1
R20_SQUISH   107
R20_TEST   2
R20_WORST_OF_FIDONET   12
RAR   0/9
RA_MULTI   106
RA_UTIL   0/162
REGCON.EUR   0/2056
REGCON   0/13
SCIENCE   0/1206
SF   0/239
SHAREWARE_SUPPORT   0/5146
SHAREWRE   0/14
SIMPSONS   0/169
STATS_OLD1   0/2539.065
STATS_OLD2   0/2530
STATS_OLD3   0/2395.095
STATS_OLD4   0/1692.25
SURVIVOR   0/495
SYSOPS_CORNER   0/3
SYSOP   0/84
TAGLINES   0/112
TEAMOS2   0/4530
TECH   0/2617
TEST.444   0/105
TRAPDOOR   0/19
TREK   0/755
TUB   0/290
UFO   0/40
UNIX   0/1316
USA_EURLINK   0/102
USR_MODEMS   0/1
VATICAN   0/2740
VIETNAM_VETS   0/14
VIRUS   0/378
VIRUS_INFO   0/201
VISUAL_BASIC   0/473
WHITEHOUSE   0/5187
WIN2000   0/101
WIN32   0/30
WIN95   0/4288
WIN95_OLD1   0/70272
WINDOWS   0/1517
WWB_SYSOP   0/419
WWB_TECH   0/810
ZCC-PUBLIC   0/1
ZEC   4

 
4DOS   0/134
ABORTION   0/7
ALASKA_CHAT   0/506
ALLFIX_FILE   0/1313
ALLFIX_FILE_OLD1   0/7997
ALT_DOS   0/152
AMATEUR_RADIO   0/1039
AMIGASALE   0/14
AMIGA   0/331
AMIGA_INT   0/1
AMIGA_PROG   0/20
AMIGA_SYSOP   0/26
ANIME   0/15
ARGUS   0/924
ASCII_ART   0/340
ASIAN_LINK   0/651
ASTRONOMY   0/417
AUDIO   0/92
AUTOMOBILE_RACING   0/105
BABYLON5   0/17862
BAG   135
BATPOWER   0/361
BBBS.ENGLISH   0/382
BBSLAW   0/109
BBS_ADS   0/5290
BBS_INTERNET   0/507
BIBLE   0/3563
BINKD   0/1119
BINKLEY   0/215
BLUEWAVE   0/2173
CABLE_MODEMS   0/25
CBM   0/46
CDRECORD   0/66
CDROM   0/20
CLASSIC_COMPUTER   0/378
COMICS   0/15
CONSPRCY   0/899
COOKING   32956
COOKING_OLD1   0/24719
COOKING_OLD2   0/40862
COOKING_OLD3   0/37489
COOKING_OLD4   0/35496
COOKING_OLD5   9370
C_ECHO   0/189
C_PLUSPLUS   0/31
DIRTY_DOZEN   0/201
DOORGAMES   0/2061
DOS_INTERNET   0/196
duplikat   6002
ECHOLIST   0/18295
EC_SUPPORT   0/318
ELECTRONICS   0/359
ELEKTRONIK.GER   1534
ENET.LINGUISTIC   0/13
ENET.POLITICS   0/4
ENET.SOFT   0/11701
ENET.SYSOP   33904
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   24128
FIDONEWS_OLD1   0/49742
FIDONEWS_OLD2   0/35949
FIDONEWS_OLD3   0/30874
FIDONEWS_OLD4   0/37224
FIDO_SYSOP   12852
FIDO_UTIL   0/180
FILEFIND   0/209
FILEGATE   0/212
FILM   0/18
FNEWS_PUBLISH   4408
FN_SYSOP   41679
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13599
FUNNY   0/4886
GENEALOGY.EUR   0/71
GET_INFO   105
GOLDED   0/408
HAM   0/16070
HOLYSMOKE   0/6791
HOT_SITES   0/1
HTMLEDIT   0/71
HUB203   466
HUB_100   264
HUB_400   39
HUMOR   0/29
IC   0/2851
INTERNET   0/424
INTERUSER   0/3
IP_CONNECT   719
JAMNNTPD   0/233
JAMTLAND   0/47
KATTY_KORNER   0/41
LAN   0/16
LINUX-USER   0/19
LINUXHELP   0/1155
LINUX   0/22093
LINUX_BBS   0/957
mail   18.68
mail_fore_ok   249
MENSA   0/341
MODERATOR   0/102
MONTE   0/992
MOSCOW_OKLAHOMA   0/1245
MUFFIN   0/783
MUSIC   0/321
N203_STAT   926
N203_SYSCHAT   313
NET203   321
NET204   69
NET_DEV   0/10
NORD.ADMIN   0/101
NORD.CHAT   0/2572
NORD.FIDONET   189
NORD.HARDWARE   0/28
NORD.KULTUR   0/114
NORD.PROG   0/32
NORD.SOFTWARE   0/88
NORD.TEKNIK   0/58
NORD   0/453
OCCULT_CHAT   0/93
Möte OSDEBATE, 18996 texter
 lista första sista föregående nästa
Text 5369, 284 rader
Skriven 2005-06-24 16:17:30 av Rich (1:379/45)
   Kommentar till text 5367 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_0017_01C578D8.38F0A050
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   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.  =

  >
  >  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_0017_01C578D8.38F0A050
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>&nbsp;&nbsp; No, the ODBC SQLStatistics =
API does=20
not identify the primary index just as I stated earlier.&nbsp; The level = 2
API=20
you suggest SQLPrimaryKeys is buggy.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; If oracle is returning the =
correct=20
data why were you complaining that you get the wrong data?&nbsp; Why are = you
so=20
steadfast in refusing to support your assertion with anything more than =
repeated=20
assertion?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Rich</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</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'" &lt;<A =
href=3D"mailto:mike@barkto.com">mike@barkto.com</A>&gt;=20
  wrote in message <A=20
  =
href=3D"news:th0pb1lvtlskallhmns5ji6ns2cn5k1rn9@4ax.com">news:th0pb1lvtls=
kallhmns5ji6ns2cn5k1rn9@4ax.com</A>...</DIV><BR>You're=20
  really not suggesting that MS Access uses the wrong API because<BR>it =
is=20
  buggy?&nbsp; That's hilarious.<BR><BR>Previously you said, "The ODBC =
API=20
  doesn't identify the primary index."<BR>Now you post saying that the =
ODBC API=20
  does identify the Primary index.<BR>You really should stick to one=20
  story.<BR><BR>Additionally, MS SQL server also has the same problem, =
(unless=20
  of<BR>course, the KB article was wrong, as you say about the=20
  security<BR>article).&nbsp;&nbsp; So it is not a matter of Oracle =
returning=20
  bad data.&nbsp; Once we<BR>worked around the ODBC API problem, Oracle =
is=20
  returning precisely the<BR>correct data.<BR><BR>&nbsp;/m<BR><BR><BR>On =
Fri, 24=20
  Jun 2005 00:19:11 -0700, "Rich" &lt;@&gt; =
wrote:<BR><BR>&gt;&nbsp;&nbsp; Nice=20
  spin on own your earlier attempts to lay blame for you getting bad =
results=20
  from your oracle database.&nbsp; We can ignore that which index if any =
is the=20
  "primary" index is not relevant despite you trying to assert a=20
  connection.&nbsp; What you fail to mention about that thread is that =
beside=20
  your assertion and your repeated attempts to spread blame elsewhere =
you never=20
  identified what was wrong, what you changed to get the correct results =
from=20
  oracle, and some evidence to support your disparaging =
statements.&nbsp; Do you=20
  really want to discuss why your make disparaging remarks but make a =
diversion=20
  when asked to back up your claims?<BR>&gt;<BR>&gt;&nbsp;&nbsp; As for =
your new=20
  attempts to question why SQLPrimaryKeys may not be used, a simple =
answer is=20
  that it is often buggy, its level 2 not level 1, and other than UI to =
display=20
  a linked table's definition it doesn't matter.&nbsp; See <A=20
  =
href=3D"http://support.borland.com/entry.jspa?externalID=3D1623&amp;categ=
oryID=3D333">http://support.borland.com/entry.jspa?externalID=3D1623&amp;=
categoryID=3D333</A>=20
  for an example of it returning incorrect results for oracle.&nbsp; 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.&nbsp; =
You=20
  probably should avoid calling SQLPrimaryKeys for mysql too.&nbsp; See =
<A=20
  =
href=3D"http://bugs.mysql.com/bug.php?id=3D3797">http://bugs.mysql.com/bu=
g.php?id=3D3797</A>.<BR>&gt;<BR>&gt;Rich<BR>&gt;<BR>&gt;&nbsp;=20
  "Mike '/m'" &lt;<A =
href=3D"mailto:mike@barkto.com">mike@barkto.com</A>&gt; wrote=20
  in message <A=20
  =
href=3D"news:v4dmb15fampi1025tim8ssifm43kqusg1f@4ax.com">news:v4dmb15famp=
i1025tim8ssifm43kqusg1f@4ax.com</A>...<BR>&gt;&nbsp;=20
  On Thu, 23 Jun 2005 06:24:23 -0400, "Geo" &lt;<A=20
  href=3D"mailto:georger@nls.net">georger@nls.net</A>&gt;=20
  wrote:<BR>&gt;<BR>&gt;&nbsp; &gt;"John Cuccia" &lt;<A=20
  href=3D"mailto:jcuccia@bigfoot.com">jcuccia@bigfoot.com</A>&gt; wrote =
in=20
  message<BR>&gt;&nbsp;=20
  &gt;news:u1djb1dkjvvqk9j4clgajl86tuhtsott6j@4ax.com...<BR>&gt;&nbsp; =
&gt;&gt;=20
  Well, I've read the thread between you and Geo and I am=20
  confused.<BR>&gt;&nbsp; &gt;&gt;<BR>&gt;&nbsp; &gt;&gt; Would you mind =

  explaining again, please?<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt;He's =
worried=20
  that if he explains in plain terms that it might be news =
(I<BR>&gt;&nbsp;=20
  &gt;would think deliberately inaccurate security bulletins would be a=20
  news<BR>&gt;&nbsp; &gt;worthy item) and he might get quoted and then =
he might=20
  get in trouble for<BR>&gt;&nbsp; &gt;telling the truth when it's =
pretty=20
  obvious that MS isn't interested in the<BR>&gt;&nbsp; &gt;truth being=20
  known.<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt;I don't want Rich to ever =
get in=20
  trouble for talking to us, do you?<BR>&gt;<BR>&gt;&nbsp; I'd never =
want anyone=20
  to get into trouble for what is posted here.&nbsp; =
<BR>&gt;<BR>&gt;&nbsp; I am=20
  just not convinced that is Rich's reason for being so =
obstinate<BR>&gt;&nbsp;=20
  here.&nbsp; He was similarly obstinate when I brought up the problem =
with=20
  MS<BR>&gt;&nbsp; Access returning the wrong data via an ODBC =
connection.&nbsp;=20
  He even said<BR>&gt;&nbsp; that the ODBC API doesn't identify the =
primary=20
  index, even though there<BR>&gt;&nbsp; is an SQLPrimaryKeys ODBC call =
which=20
  does return the primary key.&nbsp; I<BR>&gt;&nbsp; even posted a link =
to that=20
  ODBC call on Microsoft's site.&nbsp; Why doesn't<BR>&gt;&nbsp; MS =
Access use=20
  it, instead of posting a "working as designed" KB=20
  article.<BR>&gt;<BR>&gt;&nbsp; When I tried to get clarification on =
that=20
  thread, all I received was the<BR>&gt;&nbsp; similar barrage of ad =
hominem=20
  insults that I have been receiving here on<BR>&gt;&nbsp; the buffer =
overrun=20
  topic.<BR>&gt;<BR>&gt;&nbsp; On the other hand, if Rich does not want =
to have=20
  to answer questions in<BR>&gt;&nbsp; threads because he may fear being =
quoted,=20
  as you say, then maybe it<BR>&gt;&nbsp; would be better for him to =
just stay=20
  out of the thread or not answer the<BR>&gt;&nbsp; questions, instead =
of=20
  throwing insults.&nbsp; <BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;=20
/m<BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0017_01C578D8.38F0A050--

--- BBBS/NT v4.01 Flag-5
 * Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)