home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / database / sybase / 702 next >
Encoding:
Text File  |  1993-01-21  |  2.9 KB  |  96 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 Tue, 19 Jan 1993 13:44:19 GMT
  6. Message-ID: <WFINNERT.93Jan20231914@larry.shearson.com>
  7. Sender: news@shearson.com (News)
  8. Organization: Lehman Brothers
  9. References: <1993Jan19.134419.27020@eplrx7.es.duPont.com>
  10. Date: Thu, 21 Jan 1993 04:19:14 GMT
  11. Lines: 83
  12.  
  13. >In article <1993Jan19.134419.27020@eplrx7.es.duPont.com> hanafey@eplrx7.es.dupont.com (Mike Hanafey) writes:
  14.  
  15. >    Sybase returns the wrong result for the following simple query:
  16. >
  17. >       1> select c.c1 from c where (select count(*) from b where b.c1 = c.c1) > 1
  18. >       2> go
  19. >        c1          
  20. >        ----------- 
  21. >              2 
  22. >              2 
  23. >              3 
  24. >              3 
  25. >              3 
  26. >       (5 rows affected)
  27. >
  28. >   Given the tables below, the correct result should be zero rows selected:
  29.  
  30.     
  31.    [ tables deleted ]
  32.  
  33.    This type of query *DOES* work in 4.0.1. 
  34.    First make sure you have the latest 4.9.1 EBF.
  35.    Second add a "group by b.c1" to the subquery that might well fix it.
  36.  
  37.  
  38. >  Sybase also returns incorrect results for a query with a "group by" that includes
  39. >  the Transact-SQL extension that not every column in the select list must be an
  40. >  aggregate, or a grouped by column:
  41. >
  42. >       1> select b.c1,b.c2,a.c1,count(a.c2) from a,b where a.c1=b.c1 group by a.c1
  43. >       2> go
  44. >       c1          c2          c1                      
  45. >       ----------- ----------- ----------- ----------- 
  46. >            1           0           1           3 
  47. >            2           0           1           3 
  48. >            3           0           1           3 
  49. >            1           0           2           3 
  50. >            2           0           2           3 
  51. >            3           0           2           3 
  52. >       (6 rows affected)
  53. >
  54. >   The first column here contains "3", a curious result considering that this column was
  55. >   equi-joined to the third column, which has no "3". Here are the input tables:
  56. >
  57. >       1> select * from b
  58. >       2> go
  59. >       c1          c2          
  60. >       ----------- ----------- 
  61. >             1           0 
  62. >             2           0 
  63. >             3           0 
  64. >       (3 rows affected)
  65. >
  66. >       1> select * from a
  67. >       2> go
  68. >        c1          c2          
  69. >        ----------- ----------- 
  70. >            1           1 
  71. >            1           2 
  72. >            1           3 
  73. >            2           1 
  74. >            2           1 
  75. >            2           1 
  76. >       (6 rows affected)
  77.  
  78. Answer: Include all the non-aggr cols in the select list in the "GROUP BY"
  79.         or use COMPUTE.
  80.  
  81.         Despite documentation to the contrary, attempts to do otherwise
  82.         ( esp. with joins ) result in BUG-city.
  83.  
  84.  
  85. >   Mike Hanafey
  86. >   Dupont Experimental Station
  87. >   hanafey@suncity.es.dupont.com
  88. >   -- 
  89.  
  90. Good luck.
  91. --
  92. warren finnerty      | 388 Greenwich St.
  93. Lehman Brothers      | NYC NY 10013
  94. "Back off man!"      | wfinnert@shearson.com
  95.  
  96.