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   1123
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   3249
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/13300
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/341
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/4289
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   33421
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/2065
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   33945
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   24159
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   4436
FN_SYSOP   41706
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13613
FUNNY   0/4886
GENEALOGY.EUR   0/71
GET_INFO   105
GOLDED   0/408
HAM   0/16074
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/22112
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   930
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 3556, 308 rader
Skriven 2005-04-10 16:49:14 av Rich (1:379/45)
   Kommentar till text 3551 av Mike '/m' (1:379/45)
Ärende: Re: s/w patents bad 4 ms...
===================================
From: "Rich" <@>

This is a multi-part message in MIME format.

------=_NextPart_000_07AB_01C53DED.3A836400
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   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_07AB_01C53DED.3A836400
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>&nbsp;&nbsp; It just goes to show that =
you see what=20
you want to see.&nbsp; Had you actually read the KB articles someone not =

prejudiced would see that that the reason an unintended index may be = selected
is=20
that ODBC does not return the primary index and that the index must be=20
guessed.&nbsp; Nowhere does it claim that wrong data is =
returned.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Rich</FONT></DIV>
<DIV>&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:6e8j51t7a8r68aktqpe4q5aqhp7h6curd7@4ax.com">news:6e8j51t7a8r=
68aktqpe4q5aqhp7h6curd7@4ax.com</A>...</DIV><BR>btw,=20
  for more info:<BR><BR>SYMPTOMS<BR>When you link (attach) a table from =
an ODBC=20
  data source, such as<BR>Microsoft SQL Server or ORACLE, and that table =

  contains more than one<BR>unique index, Microsoft Access may select =
the wrong=20
  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>=
<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>=
<BR>Notice=20
  the "This behavior is by design." under the Status category of<BR>the =
second=20
  link.<BR><BR>The existence of this problem, and Microsoft's lack of =
interest=20
  in<BR>resolving it, was noticed at the CEO and CFO level in my =
company.&nbsp;=20
  I<BR>suspect that such a cavalier attitude by Microsoft towards the=20
  validity<BR>of the results that MS Access provides will not be A =
[long-term]=20
  Good<BR>Thing for Microsoft at my company.<BR><BR>The question I =
cannot=20
  understand is how can Microsft leave such a known<BR>and critical bug =
unfixed=20
  for over ten years?<BR><BR>&nbsp;/m<BR><BR>On Sun, 10 Apr 2005 =
14:42:55 -0700,=20
  Ellen K.<BR>&lt;<A=20
  =
href=3D"mailto:72322.enno.esspeayem.1016@compuserve.com">72322.enno.esspe=
ayem.1016@compuserve.com</A>&gt;=20
  wrote:<BR><BR>&gt;That's pretty gross all right.<BR>&gt;<BR>&gt;What =
versions=20
  of Access and Oracle?<BR>&gt;<BR>&gt;I used Access 97 against Oracle =
8i at=20
  Kaiser without this problem, and<BR>&gt;know I didn't have it because =
I would=20
  periodically check the Oracle data<BR>&gt;(retrieved using Access) =
against the=20
  DB2 data on the mainframe<BR>&gt;(retrieved interactively) of which it =
was a=20
  clone.<BR>&gt;<BR>&gt;On Sun, 10 Apr 2005 12:10:42 -0400, Mike '/m' =
&lt;<A=20
  href=3D"mailto:mike@barkto.com">mike@barkto.com</A>&gt; wrote =
in<BR>&gt;message=20
  &lt;<A=20
  =
href=3D"mailto:d5ji511u416i5k7mrgpcdrrk8h8b8ljbtb@4ax.com">d5ji511u416i5k=
7mrgpcdrrk8h8b8ljbtb@4ax.com</A>&gt;:<BR>&gt;<BR>&gt;&gt;On=20
  Sun, 10 Apr 2005 09:51:59 -0400, "Geo" &lt;<A=20
  href=3D"mailto:georger@nls.net">georger@nls.net</A>&gt;=20
  wrote:<BR>&gt;&gt;<BR>&gt;&gt;&gt;"Adam Flinton" &lt;<A=20
  =
href=3D"mailto:adam@NOSPAM_softfab.com">adam@NOSPAM_softfab.com</A>&gt; = wrote
in=20
  =
message<BR>&gt;&gt;&gt;news:4258f782$1@w3.nls.net...<BR>&gt;&gt;&gt;<BR>&=
gt;&gt;&gt;&gt;=20
  Anyway....the point that was made then was along the lines of that's=20
  it<BR>&gt;&gt;&gt;&gt; for upgrades of office coz quite frankly the =
users have=20
  everything they<BR>&gt;&gt;&gt;&gt; need =
now<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;I=20
  don't think MS realizes yet what it was that powered that growth=20
  surge<BR>&gt;&gt;&gt;they had in the=20
  =
90's.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;[snip]<BR>&gt;&gt;&gt;<BR>&gt;&gt;&g=
t;As=20
  for Office, we never used it. We went with Works because our users=20
  simply<BR>&gt;&gt;&gt;don't have the skills to require more than that. =
We've=20
  got maybe 4 copies of<BR>&gt;&gt;&gt;Office&nbsp; but only so we can =
convert=20
  files we get from customers, and we<BR>&gt;&gt;&gt;convert those to =
paper=20
  &lt;g&gt;.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;When I order new computers, =
I order=20
  them without hard drives as a way to<BR>&gt;&gt;&gt;insure that I'm =
not going=20
  to pay for any new copies of an OS I'm not going<BR>&gt;&gt;&gt;to be =
using.=20
  (well except for laptops)<BR>&gt;&gt;<BR>&gt;&gt;We use MS Office =
across the=20
  board where I work.&nbsp; Unfortunately, MS<BR>&gt;&gt;Access is =
becoming=20
  entrenched as well.&nbsp; That is frightening because =
of<BR>&gt;&gt;all the=20
  problems it has, especially the one we found last week.&nbsp;=20
  MS<BR>&gt;&gt;Access seems to return "unexpected results" when used =
with an=20
  ODBC<BR>&gt;&gt;connection in some instances.&nbsp; We had production =
and=20
  accounting people<BR>&gt;&gt;making customer-affecting decisions based =
upon=20
  the bad data that MS<BR>&gt;&gt;Access was returning.&nbsp; The =
Software=20
  Engineer (one of the most senior on<BR>&gt;&gt;the team) wrote this in =
his=20
  status report:<BR>&gt;&gt;<BR>&gt;&gt;=3D=3D=3D<BR>&gt;&gt;Worked with =
[names of=20
  users and other Software Engineers deleted to<BR>&gt;&gt;protect the =
innocent]=20
  to design and implement a work-around for a<BR>&gt;&gt;stunningly =
stupid bug=20
  in Microsoft Access.&nbsp; When Access is used =
to<BR>&gt;&gt;view/update an=20
  Oracle table, it sometimes fetches the wrong rows.&nbsp; =
There<BR>&gt;&gt;is=20
  no error or warning.&nbsp; The bad data could easily be accepted and=20
  used<BR>&gt;&gt;in producing a sample, updating panelist accounts, or =
whatever=20
  the user<BR>&gt;&gt;is doing.... This bug has existed for over ten =
years, and=20
  is documented<BR>&gt;&gt;on Microsoft's web site.&nbsp; They =
apparently have=20
  no interest in=20
  =
fixing<BR>&gt;&gt;it....<BR>&gt;&gt;=3D=3D=3D<BR>&gt;&gt;<BR>&gt;&gt;For =
that=20
  particular Software Engineer to use the phrase =
"stunningly<BR>&gt;&gt;stupid=20
  bug" (he bolded and italicized it) in his status report=20
  is<BR>&gt;&gt;amazing.&nbsp; He is usually (nearly always) very =
low-key.&nbsp;=20
  *Very* low key.&nbsp; <BR>&gt;&gt;<BR>&gt;&gt;<BR>&gt;&gt;=20
  =
/m<BR>&gt;&gt;<BR>&gt;&gt;<BR>&gt;&gt;<BR>&gt;&gt;<BR></BLOCKQUOTE></BODY=
></HTML>

------=_NextPart_000_07AB_01C53DED.3A836400--

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