Уважаемые мемберы SQL-сообщества!
Тут недавно я постил пессагу (вот здесь -> ) о выбоке топ 10 по каждой группе из результатов GROUP BY, никто не ответил, ну и фиг с ним, я проблему сам решил. Просто в процессе поиска решения наткнулся я на презабавнейшую, как мне каацца, весчь, коей и хочу поделицца.
Miscrosoft, it seems, proved itself MuzDie again ибо я тут совершенно случайно набрел на два качественных способа загнать тов. SQL Server'а в полный ступор. Вот код (to reproduce behavior кому интересно):
1. Создаем тестовую табличку.

SET NOCOUNT ON

DECLARE @nNum int, @nRecNo int

CREATE TABLE #Test (dt smalldatetime, nm char(30), quant int, [Day] as (convert(char(10), [dt], 102)), cut as Left(nm, 5))

SET @nNum = 1
WHILE @Nnum <= 4
BEGIN
SET @nRecNo = Cast((40 - 5 + 1) * Rand() + 5 as int)
WHILE @nRecNo > 0
BEGIN
INSERT #Test (dt, nm, quant)
VALUES (DateAdd(Day, @nNum, GetDate()),
'Record ' + Cast(Cast((12 - 1 + 1) * RAND() + 1 as int) as varchar(3)),
Cast(10000 * Rand() as int))
SET @nRecNo = @nRecNo - 1
END
SET @nNum = @nNum + 1
END
А теперь - дискотека!
2. Выполняем нижеприведенный запрос - получаем то, что отражено в комментарии.
-- Internal SQL Server error expected
SELECT
a.[Day],
a.cut,
Sum(a.quant) AS [Incoming],
Count(a.quant) AS [HitCount]
FROM #Test a
WHERE a.cut IN
(SELECT TOP 10 b.cut FROM #Test b
WHERE b.[Day] = a.[Day]
GROUP BY b.cut
ORDER BY Sum(b.quant) DESC)
GROUP BY a.[Day], a.cut

3. Выполняем нижеприведенный запрос - получаем ишшо более ужастные резалты.
-- Fatal exception expected
SELECT
a.[Day],
a.cut,
Sum(a.quant) AS [Incoming]
FROM #Test a
GROUP BY a.[Day], a.cut
HAVING Sum(a.quant) IN
(SELECT TOP 20 Sum(b.quant) FROM #Test b
WHERE b.[Day] = a.[Day]
GROUP BY cut
ORDER BY 1 DESC)

Система, на которой тестилось все это:

Kernel version: Microsoft Windows NT, Uniprocessor Free
Product type: Enterprise Server (Domain Controller)
Product version: 4.0
Service pack: 6
Kernel build number: 1381

Microsoft SQL Server 7.00 - 7.00.961 (Intel X86)
Oct 24 2000 18:39:12
Copyright (c) 1988-1998 Microsoft Corporation
Enterprise Edition on Windows NT 4.0 (Build 1381: Service Pack 6)
7.00.961 означает Database components SP3

ODBC дрова:
SQL Server 3.70.09.61 SQLSRV32.DLL 24.10.2000

Комментарии.
1. Забавно то, что оба запроса синтаксически правильны, причем SQL Server 2000 (я тестил MSDE в данном конкретном случае) проглатывает эти пилюльки не подавившись.
2. В первом запросе достаточно убрать Count из select'а - и все начинает пахать
3. Мне не удалось "репродуцировать" эти горбы, выбирая аналогичным образом данные из pubs.dbo.sales (???)

З.Ы. Вдогонку вопрос к уважаемым монстрам рока (то биш SQL) ->
это вообще нормально, что Query Analyzer 2000 при выполнении обоих вышеприведенных запросов показывает стоимость каждого 0.00%?
Я неоднократно слышал о мягко говоря странном интерпретировании percentage этим аналайзером, а тут вот и на практике столкнулся... "Что делать?", ибо я догадываюсь "Кто виноват"...

> Печально, но средств борьбы с этим не найдено.
Печально, что разработчики от M$ до сих пор не озаботились выпуском такого средства в виде каково-нить патча что ли, блин.
Ну, да это у них в крови - горбы с определением пропертей триггеров через DMO так тоже до сих пор не исправлены - это после трех-то сервис-паков
А в даном случае выход канешна есть - переползать на SQL 2000, а аналайзер продолжать юзать от семерки