home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / database / sybase / 703 < prev    next >
Encoding:
Text File  |  1993-01-21  |  4.6 KB  |  143 lines
  1. Newsgroups: comp.databases.sybase
  2. Path: sparky!uunet!shearson.com!newshost!wfinnert
  3. From: wfinnert@larry.shearson.com (Warren Finnerty)
  4. Subject: Re: Sybase 4.9.1 Returns the Wrong Rows
  5. In-Reply-To: hanafey@eplrx7.es.dupont.com's message of Wed, 20 Jan 1993 18:37:02 GMT
  6. Message-ID: <WFINNERT.93Jan21000910@larry.shearson.com>
  7. Sender: news@shearson.com (News)
  8. Organization: Lehman Brothers
  9. References: <1993Jan19.134419.27020@eplrx7.es.duPont.com>
  10.     <1jju7fINNdtl@gazette.bcm.tmc.edu>
  11.     <1993Jan20.183702.14919@eplrx7.es.duPont.com>
  12. Date: Thu, 21 Jan 1993 05:09:10 GMT
  13. Lines: 128
  14.  
  15. In article <1993Jan20.183702.14919@eplrx7.es.duPont.com> hanafey@eplrx7.es.dupont.com (Mike Hanafey) writes:
  16. >
  17. >   In article mparsons@fleming.csc.bcm.tmc.edu (Mark Parsons) writes:
  18. >   |> 
  19. >   |> In article <1993Jan19.134419.27020@eplrx7.es.duPont.com>, hanafey@eplrx7.es.dupont.com (Mike Hanafey) writes:
  20. >   |> > Sybase returns the wrong result for the following simple query:
  21. >   |> > 
  22. >   |> >     1> select c.c1 from c where (select count(*) from b where b.c1 = c.c1) > 1
  23. >   |> >     2> go
  24. >   |> >      c1          
  25. >   |> >      ----------- 
  26. >   |> >                2 
  27. >   |> >                2 
  28. >   |> >                3 
  29. >   |> >                3 
  30. >   |> >                3 
  31. >   |> >     (5 rows affected)
  32. >   |> > 
  33. >   |> > Given the tables below, the correct result should be zero rows selected:
  34. >   |> > 
  35. >   |> >     1> select * from c
  36. >   |> >     2> go
  37. >   |> >      c1          
  38. >   |> >      ----------- 
  39. >   |> >               1 
  40. >   |> >               2 
  41. >   |> >                2 
  42. >   |> >                3 
  43. >   |> >                3 
  44. >   |> >                3 
  45. >   |> >     (6 rows affected)
  46. >   |> > 
  47. >   |> >     1> select * from b
  48. >   |> >     2> go
  49. >   |> >      c1          c2          
  50. >   |> >          ----------- ----------- 
  51. >   |> >                1           0 
  52. >   |> >                2           0 
  53. >   |> >                3           0 
  54. >   |> > 
  55. >   |> >     (3 rows affected)
  56. >   |> > 
  57. >   |> 
  58. >   |> OOO! OOOO!  I can answer this one!!!
  59. >   |> 
  60. >   |> Your nested select does a test for b.c1=c.c1.  If we go through the tables
  61. >   |> one step at a time we find that there's only one match for c1=1 so there's
  62. >   |> no row in the results for c1=1.  In the case of c1=2 we get a count = 2, 
  63. >   |> but notice that we'll get this count twice; why?  because SQL does not
  64. >   |> distinguish between duplicate rows(not in the above select), i.e., there
  65. >   |> are 2 times that b.c1 = c.c1 sooooooo, you get 2 results(the first time
  66. >   |> the 2nd row of c matches against the 2nd row of b, the second time the
  67. >   |> 3rd row of c mathces against the 2nd row of b).  Likewise on the
  68. >   |> case of c1=3; you have 3 times that b.c1=c.c1, hence 3 resultant rows of
  69. >   |> the same thing.
  70. >   |> 
  71. >   |> Therefore you get the 5 rows as shown above.  
  72. >   |> 
  73. >   |> If you want only one instance of each b.c1=c.c1 returned you could try:
  74. >   |> 
  75. >   |>     select distinct c.c1 from c where . . . . 
  76. >   |>            ^^^^^^^^
  77. >   |> 
  78. >   |> and this will give you
  79. >   |> 
  80. >   |>     c1
  81. >   |>     --
  82. >   |>     2
  83. >   |>     3
  84. >   |> 
  85. >   |> As for why you think there should be 0 rows . . .. I'm confused . . 
  86. >   |> could you explain why you think there should be 0 rows??  Just 
  87. >   |> curious . . .
  88. >   |> 
  89. >   |> Did any of this make sense?? If not let me know . . . I'm not firing on
  90. >   |> all pistons today!! ;-)
  91. >   |> 
  92. >   |> As for your other problem . . . still working on it . . . . Is
  93. >   |> Friday here, yet!!!!!!!???????  ;-)
  94. >   |> 
  95. >   |> Mark
  96. >   |> 
  97. >   |>     
  98. >
  99. >   The query is asking for rows in "c" that would join with more than one row in "b",
  100. >   and there are no rows in "c" that meet this condition (in your response you swap
  101. >   table "c" and "b", apparently this is what the Sybase optimizer does -- did you have
  102. >   a hand in writing the Sybase optimizer? ;) ).
  103. >
  104. >   If in fact this is a Sybase error, I find it very disturbing that such a simple query
  105. >   returns the wrong result.
  106.  
  107. Please ignore the first part of my previous post, I did not look close enough
  108. at the data in "c" ( no more late night posts )
  109. ( I used "sysobjects c, sysindexes b" which missed the whole point ).
  110.  
  111. In 4.0.1 the results are even *WORSE* 
  112.  
  113.  
  114. c1
  115. ---------
  116.     2
  117.     3
  118.  
  119. Yikes! This query should iterate once per outer row but the pess-imizer is
  120. turning it into a join. It gets worse.......
  121.  
  122. select b.c1, count(*) from b 
  123. where exists ( select * from c where c.c1 = b.c1 )
  124. group by b.c1
  125. having count(*) > 1
  126.  
  127. Bulletproof you think....
  128. EXISTS should prevent it from being processed as a join....
  129. No such luck.
  130.  
  131. c1
  132. --------- -------
  133.     1    1
  134.     2    2
  135.     3    3
  136.  
  137. Bummer. 
  138. --
  139. warren finnerty      | 388 Greenwich St.
  140. Lehman Brothers      | NYC NY 10013
  141. "Back off man!"      | wfinnert@shearson.com
  142.  
  143.