Запрос в SQL на остатки регистра накопления #539936

Написал в SQL запрос на получение остатков (с помощью трассировки). Получем у меня первые две записи например не схлопнулись? И так по некоторым контрагентам Вот запрос: exec sp_executesql N'SELECT #V8TblAli1_Q_000_T_001._Fld7011RRef AS f_1, #V8TblAli1_Q_000_T_001._Fld7013RRef AS f_2, #V8TblAli1_Q_000_T_001._Fld7012RRef AS f_3, #V8TblAli1_Q_000_T_001._Fld7021_TYPE AS f_4, #V8TblAli1_Q_000_T_001._Fld7021_RTRef AS f_5, #V8TblAli1_Q_000_T_001._Fld7021_RRRef AS f_6, #V8TblAli1_Q_000_T_001._Fld7014RRef AS f_7, #V8TblAli1_Q_000_T_001._Fld7015RRef AS f_8, #V8TblAli1_Q_000_T_001._Fld16599RRef AS f_9, #V8TblAli1_Q_000_T_001._Fld7016RRef AS f_10, #V8TblAli1_Q_000_T_001._Fld7017RRef AS f_11, #V8TblAli1_Q_000_T_001._Fld17097RRef AS f_12, #V8TblAli1_Q_000_T_001._Fld16600RRef AS f_13, #V8TblAli1_Q_000_T_001._Fld7018RRef AS f_14, #V8TblAli1_Q_000_T_001._Fld7019 AS f_15, #V8TblAli1_Q_000_T_001._Fld7020 AS f_16, #V8TblAli1_Q_000_T_001._Fld7022RRef AS f_17, #V8TblAli1_Q_000_T_001._Fld7023Balance AS f_18, #V8TblAli1_Q_000_T_001._Fld7024Balance AS f_19, #V8TblAli1_Q_000_T_001._Fld7025Balance AS f_20 FROM ( SELECT _AccumRegTotals7034._Fld7011RRef AS _Fld7011RRef, _AccumRegTotals7034._Fld7013RRef AS _Fld7013RRef, _AccumRegTotals7034._Fld7012RRef AS _Fld7012RRef, _AccumRegTotals7034._Fld7021_TYPE AS _Fld7021_TYPE, _AccumRegTotals7034._Fld7021_RTRef AS _Fld7021_RTRef, _AccumRegTotals7034._Fld7021_RRRef AS _Fld7021_RRRef, _AccumRegTotals7034._Fld7014RRef AS _Fld7014RRef, _AccumRegTotals7034._Fld7015RRef AS _Fld7015RRef, _AccumRegTotals7034._Fld16599RRef AS _Fld16599RRef, _AccumRegTotals7034._Fld7016RRef AS _Fld7016RRef, _AccumRegTotals7034._Fld7017RRef AS _Fld7017RRef, _AccumRegTotals7034._Fld17097RRef AS _Fld17097RRef, _AccumRegTotals7034._Fld16600RRef AS _Fld16600RRef, _AccumRegTotals7034._Fld7018RRef AS _Fld7018RRef, _AccumRegTotals7034._Fld7019 AS _Fld7019, _AccumRegTotals7034._Fld7020 AS _Fld7020, _AccumRegTotals7034._Fld7022RRef AS _Fld7022RRef, _AccumRegTotals7034._Fld7023 AS _Fld7023Balance, _AccumRegTotals7034._Fld7024 AS _Fld7024Balance, _AccumRegTotals7034._Fld7025 AS _Fld7025Balance FROM _AccumRegTotals7034 WITH(NOLOCK) WHERE _AccumRegTotals7034._Period = AND _AccumRegTotals7034._Fld7011RRef = @P2 AND (_AccumRegTotals7034._Fld7023 <> CAST(@P3 AS NUMERIC(1,0)) OR _AccumRegTotals7034._Fld7024 <> CAST(@P3 AS NUMERIC(1,0)) OR _AccumRegTotals7034._Fld7025 <> CAST(@P3 AS NUMERIC(1,0))) ) #V8TblAli1_Q_000_T_001', N' datetime,@P2 varbinary,@P3 numeric(1,0)', {ts '2011-01-01 00:00:00'}, 0xBFE11F601EA5A4C5411EA382A4F4886A, 0 Вот результат: 0xBFE11F601EA5A4C5411EA382A4F4886A    0x82B20662E86FF73547967BDC3F7D18A9    0xB01550505450303011DC39ADB47719F1    0x08    0x0000011C    0x970F0015605358D311DEF444456D7446    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0xBCFB8E8BDDC92F1A4329725CDF5321DC    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0x00000000000000000000000000000000    1753-01-01 00:00:00.000    1753-01-01 00:00:00.000    0xB00A50505450303011DB365F814D37B6    11570.00    1764.92    0.00 0xBFE11F601EA5A4C5411EA382A4F4886A    0x82B20662E86FF73547967BDC3F7D18A9    0xB01550505450303011DC39ADB47719F1    0x08    0x0000011C    0x970F0015605358D311DEF444456D7446    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0xBCFB8E8BDDC92F1A4329725CDF5321DC    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0x00000000000000000000000000000000    1753-01-01 00:00:00.000    1753-01-01 00:00:00.000    0xB00A50505450303011DB365F814D37B6    -11570.00    -1764.92    0.00 0xBFE11F601EA5A4C5411EA382A4F4886A    0x82B20662E86FF73547967BDC3F7D18A9    0xB01550505450303011DC39ADB47719F1    0x08    0x0000011C    0x97600015605358D311DFF07ED1B761B2    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0xBCFB8E8BDDC92F1A4329725CDF5321DC    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0x00000000000000000000000000000000    1753-01-01 00:00:00.000    1753-01-01 00:00:00.000    0xB00A50505450303011DB365F814D37B6    34867.89    5318.82    0.00

дык group by и агрегирующей функции нема..

а зачем мне делать group by, когда он и так свернуть должен. А если делать group by, то эти две записи в принципе должны пропасть, но появляется такая запись: 0xBFE11F601EA5A4C5411EA382A4F4886A    0x82B20662E86FF73547967BDC3F7D18A9    0xB01550505450303011DC39ADB47719F1    0x08    0x0000011C    0x970F0015605358D311DEF444456D7446    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0xBCFB8E8BDDC92F1A4329725CDF5321DC    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0x00000000000000000000000000000000    0x00000000000000000000000000000000    1753-01-01 00:00:00.000    1753-01-01 00:00:00.000    0xB00A50505450303011DB365F814D37B6    00.00    00.00    0.00

> >>group by и агрегирующей функции

разделение итогов включено?

ну так это не не всех так. где оно включается?

только у некоторых контрагентов.

а как ты одну "строку" получишь, если у тебя их в итогах 5, например ?

пять не получу. но согласитесь эти записи должны схлопнуться?

ведь я беру остатки по измерениям!

как исправить данную ошибку? В платформе ничего не помогло. Может в sql как-то?

нет. С какой радости ?

у тебя обычный селект из таблички, с какой радости, что-то "схлопнутся" должно ?

У меня необычный запрос, а запрос по остаткам. Например:

ага, зачет, показывая с обычным селектом и догадываться что это кусок кода из запроса к ВТ ?

в первом посте - это необычный селект. там виртуальная таблица используется. это запрос из профайлера взят.

я тоже у себя проверял на конфигурации типовой. но у меня все свернулось. к сожалению, я не знаю в чем у Вас может быть проблема.

вообще никаких средств нет?

чем вас -то не устраивает? Все ж правильно сказали... а по каким полям вы group by делали? Все правильно он сворачивает, если вы делаете по всем полям кроме "числовых". У вас все правильно свернуло - шестая "колонка" в приведенных результатах в первых двух записях одинаковая, в третьем - отличается. Если она участвует в group by - результат будет такой, какой вы привели. угу.. и sql server, конечно, знает что такое "виртуальная таблица"...

так в первых двух записях одинаковое все. почему эти две записи не свернулись без group by? Это же виртуальная таблица остатков. не должно быть одинаковых записей по всем измерениям в результате и без grop by.

Причем что интересно. Я убрал из запроса семдьмую колонку (можно 5 или 6 например), то записи сворачиваются. почему так?