hvladТаблоидчто такое "контекст" ?Во время выполнения запрос вычисляет и хранит состояние каждого потока данных (таблицы в простейшем случае).
Грубо говоря - текущую запись из каждого потока.
Операторы BLR принимают номера потоков (контекстов) как параметры.
Номер контекста кодируется 1 байтом, отсюда ограничение.
Т.е. если какой-нибудь генератор sql-кода сгенерит 256 джойнов одним селектом, то всё пропало?
Если это так, то можно ли отодвинуть это ограничение хотя бы до размера word?

У меня вот 175 джойнов генерится, при этом вытаскиваются 560 полей из примерно 30 таблиц. Это для печати отчёта. Лишних полей там нет, т.е. они либо печатаются, либо участвуют в вычислениях в отчёте. Это не табличный отчёт, а одностраничный документ с детальными характеристиками покупаемого изделия (много цифр, много букв).
И запрос уже на 45 килобайт... Простой селект одной записи с кучей джойнов.

И я вполне допускаю, что со временем система может перешагнуть и через 64K на этом запросе, и через 256 джойнов.
Я могу конечно запрос побить на два, причём прозрачно для отчётера (fastreport), на уровне кода сервера приложений. Но имхо универсальней будет убрать ограничение в дальние дали :)

hvladNickDeeможно ли отодвинуть это ограничение хотя бы до размера word?Нет.
Что-то поломается?

Гаджимурадов РустамNickDee> Т.е. если какой-нибудь генератор sql-кода сгенерит
NickDee> 256 джойнов одним селектом, то всё пропало?

Почему всё пропало? Ни с сервером, ни с БД
ничего не происходит, а запрос не выполнится, да.

Вот представь, что у тебя есть табличка, в которой среди прочих есть четыре поля: FirstDocId, SecondDocId, ThirdDocId, FourthDocId (ссылаются на одну табличку Docs). И у тебя есть вьюшка по таблице.
И вот тебе говорят, что во вьюшку нужно добавить четыре поля:
FirstDocId.ManagerId.ServerId.DealerId.CountryId.Name
SecondDocId.ManagerId.ServerId.DealerId.CountryId.Name
ThirdDocId.ManagerId.ServerId.DealerId.CountryId.Name
FourthDocId.ManagerId.ServerId.DealerId.CountryId.Name

Каждое такое поле развернётся в 5 joins, итого +20.

Понятно что имея инструмент, который позволяет строить такие вьюшки на раз-да, без написания sql вручную, то можно вполне наступить на ограничение в 256 joins на сложных базах.
У меня база совсем не сложная по структуре, а 175 joins на запрос уже есть.

Гаджимурадов РустамNickDee> Вот представь

Зачем? Способов создать себе проблемы я итак больше тебя знаю.

Проблем нет, пока ты не наступаешь на ограничение.
Вот начинаешь работать с движком БД, а там - то ограничение на количество элементов в IN, то на размер стейтмента, то на размер таблицы, то на длину имени поля, то на суммарный размер всех полей в таблице.

Лично я наступил на ограничение с IN, на размер стейтмента, на ограничение длины поля. Пришлось выкручиваться.

Спрашиваешь - почему бы не изменить такое поведение? В ответ получаешь телегу как правильно писать. В том-то и дело, что писать надо так, чтобы не создавать глупых ограничений :) А если они унаследованы из чужого кода, и пользователи просят изменить ограничение пока никто не наступил, то почему это просто не сделать?

kdvNickDeeСпрашиваешь - почему бы не изменить такое поведение? В ответ получаешь телегу как правильно писать
дай вам волю, вы процедуры по 10 мегабайт писать будете.

И что конкретно тебя в этом пугает? :) Ну будут у меня стейтменты по 10 мегабайт, или по сто. Мне так удобно, и мне с ними жить :)
Почему я должен быть ограничен константой в коде? Просто потому что кто-то решил что конкретного N должно хватить на все задачи, доступные к осознанию того кто ставит этот N? :) А если некоторые задачи не подвластны его осознанию? :)

kdvNickDeeто почему это просто не сделать?
потому что ряд подобных изменений требует изменений в движке, которые могут повлиять неизвестно на что. И потому что не бывает софта без ограничений. Всегда есть какой-то лимит, и всегда на этот лимит кто-то наступит, обязательно.
Есть лимиты старые, которые можно или легко или с определенными усилиями изменить. И они меняются. Например, 36 гиг на одну таблицу, разрядность генератора, Next transaction, ... Ну растут данные, что поделать. Но есть определенные лимиты, которые выходят за здравый смысл.
Например, размер оператора. В ЯП ведь уже много лет есть правило - размер процедуры не должен превышать размер экрана (допустим, 120 строк). Почему в SQL это можно "нарушать"?

Потому что стейтменты могут быть сгенерённые. Собственно при генерации кода для триггера я и наступил на ограничение.

kdvА с IN - насколько бы тебе его увеличить хотелось? 2500? 5000? 10000? Я гарантирую, что после увеличения до 10к обязательно тут же кто то на это наступит.
Я наступил на 1500. И естественно это была автогенерация кода :) Пользователь в гриде выделял записи, и я их для групповой обработки вставлял в "where ID in (...)".
Ограничение должно быть как можно выше, и я бы не стал ограничиваться размером WORD. Пусть работает медленней, пусть противоречит чьей-то девелоперской совести, но пусть работает... это уже будет выбор того, кто это использует.

Dimitry SibiryakovNickDeeПользователь в гриде выделял записи, и я их для групповой обработки вставлял
в "where ID in (...)".
Потому что использовать для этого временную таблицу у тебя не хватило... чего?

Ты сейчас спрашиваешь о том, почему я вместо того чтобы написать простой "where ID in (...)", не создал временную таблицу, потом не сделал в неё N инсертов, а потом не написал "where Id in select from ..."? :) Ты сейчас про это спрашиваешь? :)

Dimitry SibiryakovNickDeeТы сейчас про это спрашиваешь? :)

Именно так. Только не in, а join.

если делать с джойном, то тогда лучше без временной таблицы. Мы это тут обсуждали пять лет назад: 6343890 :)
Но это настоящий изврат, правда меньший чем с инсертами :) Быстро работает, да. Но изврат :)

ТаблоидNickDeeесли делать с джойном, то тогда лучше без временной таблицы. Мы это тут обсуждали пять лет назад: 6343890 :)
Но это настоящий изврат, правда меньший чем с инсертами :) Быстро работает, да. Но изврат :)0xFF.
2 NickDee: ты там разбиваешь список ИДшников на "слова" и выдаёшь из процедуры наружу отдельные ИДшники - я правильно понимаю ?
Да.
ТаблоидЧто делает с входным блобом (IntStr) твоя УДФ CreateIntList(IntStr, ListId, Cnt) ?
Она создаёт из блоба IntStr список чисел, возвращает ассоциированный с этим списком ListId, и возвращает в Cnt количество элементов в списке.
ТаблоидИ откудова вытаскивает ID'шник вот эта штука: ValueInList(ListId, I, V) ? (ListId - это же integer, а не блоб... я слабо как-то понимаю тамошний код...)
Она вытаскивает их из списка, который ассоциирован с ListId.
Кстати Blob это же реально Int64, привязанный к данным, и имеющий методы работы с этими данными :) Вот тут по аналогии: ListId привязан к списку, и есть методы работы с этим списком.

Гаджимурадов Рустамkdv> ой, опять про выделение пользователем в гриде полутора тысяч записей....
Да на самом деле там где-нибудь "выделить все" или
выделить диапазон, а обработать нормально это дело
автору лень, нехай сервер трудится, он же железный.

Ну ты знаешь, у меня код в скриптах прописан, и достаточно сильно абстрагирован от грида.
Там (в скрипте) торчит функция, типа GetMarkedIdList: TIntegerDynArray.
С моей точки зрения именно список Id из грида и является теми данными, которые ожидает скриптовая процедура обработки, желающая обработать отмеченные записи :) Я так и реализовал.
Я эту функцию вызываю, получаю список отмеченных Id, и в скрипте пишу например такой sql-запрос: "update T set IsProcessed = 1 where Id in (' + IntListToStr(GetMarkedIdList) + ')".
Почти одной строчкой. Все шаги очевидны и понятны. А вы что предлагаете? :)

Я sql-серверу на его собственном языке говорю: поставь IsProcessed = 1, для записей у которых Id принадлежит указанному множеству значений.
Чего не так? :)

Dimitry SibiryakovNickDeeЯ эту функцию вызываю, получаю список отмеченных Id, и в скрипте пишу
например такой sql-запрос: "update T set IsProcessed = 1 where Id in (' +
IntListToStr(GetMarkedIdList) + ')".
Почти одной строчкой. Все шаги очевидны и понятны. А вы что предлагаете? :)
Две строки:


Все шаги очевидны и понятны.

Это я понимаю.
Можно, чтобы не переписывать существующий sql-код, пойти ещё дальше - распарсить sql, вытащить из него элементы IN, вставить их во временную таблицу, исправить sql на join или merge, и отдать серверу :)
Будет почти универсальный воркэраунд для IN. Но это и есть изврат :)