Доброе время суток,

в некоторых случаях отказаться от execute statement не получается и встаёт вопрос а как наложить зависимости на участников execute statement. До сих пор приходилось выкручиваться через type of column для входных, выходных и прочих переменных. Но зачастую в строке запроса используются поля которые незачем куда то вытаскивать создавая для них переменные или выходные параметры а зависимость на них и их содержащие таблицы должна существовать. Как Вы поступаете в подобных случаях?

не рисовать же рядом тупо запросы которые ничего не возвращают или переменные (c type of column) которые никому не нужны дабы только создать на них зависимость?

возможно есть другая, более красивая, возможность прописать зависимость без извращений, которая мне неизвестна?

Идеален был бы просто оператор создания зависимости, но найти такой мне не удалось.

поделитесь

я уже поднимал раньше эту тему тут
но красивого решения не вижу и по сей день

Симонов ДенисMikhail Tchervonenko,
....
Лучше бы показали задачу где без execute statement не обойтись. Тогда может чего и подсказали бы
ну к примеру, ORDER BY создаётся динамически и список полей передаются в процедуру через запятую в виде строки и имена полей ещё надо допилить примерно так I_ORDER_BY = replace(I_ORDER_BY,'O_IDCOUNTRY','PARTNERS.id_country');
т.к. имена полей на клиенте отличаются от имен полей в базе (выходящие данные с префиксом O_, а исходящие с I_)
сие не мои идеи по именованию и менять там что то уже поздно, да и никто не даст. (замечу что речь не всегда идёт о сортировке выходных данных в самом гриде, иногда это сортировка вромежуточных результатов в процедуре).

а адея формирования блока на клиенте мне нравится не очень ввиду потенциальных проблем с универсальностью. Прийдётся отказаться от компонентов в виде допиленных Gridов которые автоматом сами передают список полей (с префиксом) в процедуру выборки.

Мимопроходящийи эти люди сетуют, что до них базу курочили "мальчики по вызову"...

это как раз пример танцев с результатами работы тех самых мальчиков. Когда приходишь и говоришь что все надо переделывать а тебе говорят нет, вы только тут и тут поправьте и улучшите. Все денег стоит.

я собственно в основном эту дискуссию затеял зная что сюда разработчики заглядывают FB. Чем черт не шутит, если реализовали уж execute statement то почему не сделать и оператор создания зависимости, как раз для таких случаев.

hvladMikhail Tchervonenkoв некоторых случаях отказаться от execute statement не получается и встаёт вопрос а как наложить зависимости на участников execute statement.А зачем ?

PS а как наложить зависимости на запросы, выдаваемые приложением ?

если под приложением понимается клиент то в идеале он вообще не должен работать с таблицами на прямую, только с хранимками. По крайней мере в том что пишу я нет ни одного запроса из таблицы напрямую, только из хранимок. Абсолютно 100%. Другими словами вся логика должна сидеть в базе. Это касается и проектов на FB и на MSSQL. Исключение только MySQL т.к. хранимки там появились сравнительно недавно и по отзывам ещё не всё допилено.

Симонов ДенисMikhail Tchervonenko,

хрень твоя идея с зависимостями. Ибо в качестве параметра сортировки мне никто не помешает передать




....

ну да, если туда пальцами набивать эти строки то конечно. А вот когда эти строки формирует компонент на клиенте на основе своих же свойств полей и ты знаешь что прийдёт в хранимку, то вопрос только в комбинации пришедшего и предварительной обработке.
Заметьте, я хочу просто прописать в хранимке зависимости из execute statement. Остальные вопросы уже решены, и на клиенте нет логики на которую нужно накладывать эти зависимости. И походу, как уже писали раньше, кроме неисполняемого блока кода в этой хранимке, решения нет.

Dimitry SibiryakovMikhail Tchervonenkoнет ни одного запроса из таблицы напрямую, только из хранимок.
Абсолютно 100%.
Ужоснах.

когдато, фирма для которой писали софт вызвала Gutachter, типа эксперт от мелкософта (проект был на MSSQL + С#) который лазил по проекту и выискивал в том числе и прямые обращения к таблицам (на уовне select и на уровне компонентов). И таки нашел пару забытых временных затычек, это стоило нам денег. Если проект должен без проблем работать на нескольких платформах и различных клиентах иного решения нет. Все остальное стоит гораздо дороже в итоге и по деньгам и по времени. И я с тим на все 100% согласен. Опыт неоднократно подтвердил правильность такого подхода. Опять же это позволяет гораздо лучше контроллировать те же зависимости, да и тестирование сильно упрощается.