>Ну как, уже не клинит?
на празднике был - другу (и куму) 26 лет... Как думаете, не клинит? :)

а вообще-то, почитал я вас, да и впал в уныние... Нет, я рад, конечно, что в данный топик заглянули одни из самых крутых (без иронии) завсегдатоев форума, но... Но вопрос был до нельзя понятным: "как передать классу два SQL-запроса - либо уже имеющийся сохраненный, либо в кусках динамически формируемый", а я чувствую, что меня начинают опускать :(

для V. Motchulsky
>Вопрос может ли товар с одной группы входить в другую, то есть быть одновременно в двух группах?
Может. Модель пересекающихся множеств. На примере: Товар Шампунь Шамту 400 мл для Сухих волос. Входит в следующие множества (группы):
- Группа ШАМПУНИ (множество КАТЕГОРИЯ ТОВАРА);
- Группа P&G (множество ПРОИЗВОДИТЕЛЬ ТОВАРА);
- Группа Поставщик Х (множество ПОСТАВЩИК ТОВАРА);
- Группа Прайс №3 (множество ПРАЙСЫ);
- Группа ШАМТУ (множество СЕРИИ ТОВАРА)
...

>Зачем проводить синтетический анализ запроса, он что пользователем будут создаваться?
Говорил же, что производится попытка создать КОМПОНЕНТ или, на худой конец, облегчить подключение данной смешной хрени в новые проекты. Поэтому да, создаваться запрос будет пользователями компонента, т.е. разработчиками проекта.

>Я тут дочитался... Чутье подсказывает что не те параметры надо передавать или существует более простое, более элегантное решение.
Вообще-то, в простейшем случае передавать надо только запрос (либо именем сохраненного запроса, либо целой строкой SQL-кода, при этом наличие такой возможности продиктованно сразу несколькими факторами, не рассматриваемыми здесь), который будет возвращать Группу или Источник для группы (что есть абсолютно разные вещи и вернуть их одним запросом, поменяв в нем лиш один-два параметр, не удастся), но это лишь в ПРОСТЕЙШЕМ случае! Реально мне нужна корректировка предложения СЕЛЕКТ, ВЕР и предложения ОРДЕР. Более того, если в грид передается имя сохраненного запроса, то я на лету формирую еще один запрос, в котором и корректирую эти самые три предложения, и уже затем подсовываю его непосредственно гриду. Нахр это надо? Рассказываю... Целевой грид может иметь, ну скажем, 15 полей (столбцов), при этом при работе... Не... На примере... При приеме товара от Поставщика Х оператору необходимо кроме некоторых стандартных полей (наименование товара, цена поставщика, кол-во и т.п.) еще и дополнительные, которые не нужны для приема товара от Поставщика Y (например Артикул товара, который указывает в накладных поставщик и по которому оператору легче находить товар, Срок годности, если Поставщик доставляет скоропортящиеся продукты и т.п.). Так вот при простом, не редактируемом запросе все эти дополнительные данные вытягиваются из БД, хотя оператору они нахр не нужны и более того, даже не отображаются на экране в присвоенной конкретному поставщику Схеме настройки целевого грида. А при редактируемом запросе , из предложения СЕЛЕКТ все эти неотображаемые поля выкидываются и всем счастье! (На самом деле не все поля выкидываются, даже если не отображаются, а только поля, имеющие статус Информативных, а Операционно-индикаторные поля, которые могут использоваться для каких-либо рассчетов, например, Цена товара, даже если не отображаются в гриде, то все равно запрашиваются у БД).
Кроме этого, редактировать предложение СЕЛЕКТ мне нужно из-за, опять же, смешного интерфейсного ноу-хау, которое позволяет избавиться во всем проекте от всяких переключателей, типа, "Показывать цену по приходу, Показывать цену по Реализации, среднюю, фактическую, в долларах, в дохлых енотах", а просто напросто брать, и через интуитивный, удобный, и афигительно эффективный способ указывать в гриде что надо показывать! Кстати, а что, если заказчик попросит вас добавить еще какую-нибудь фичу, требующую втыкивания в главную форму (как везде и делается) еще кучи переключателей? Например, по введению нескольких названий для одного и того же товара? Т.е. название товара "Для склада" (так, как называет товар Склад), "Для Оператора" (так, как оператору удобней искать данный товар), "Для Прайс-листов" (так, как требуют Торговые представители, дабы сделать прайсы однородными и легко воспринимаемыми), "Для Поставщиков" (так, как товар числится у поставщика), "На английском" и т.п. Заказчик, конечно, не предложит такого, ибо от операторов до разработчиков эта идея вызвала шок, но я, как бывший управленец в сфере оптовой торговли, точно знал (теоретически:) что это здорово и, практически насильно впихнул это чудо одному из клиентов, который затем был просто в восторге! Да! Система двойственных наименований заставляет больше вводить и редактировать данных, повышает нагрузку на БД, но скорость и качество работы фирмы от этого просто взлетают! Оператор принимая товар от поставщика не пытается вспомнить, как же этот самый товар называется внутри фирмы, а просто открывает названия товара в том виде, в котором он числится у этого поставщика и спокойно работает! Оператор вбивая заказ из прайсов не вспоминает, как числится товар по базе, а просто открывает наименование по прайсам и работает! Склад отбирает товар по отборным листам, в которых такие наименования товара, которые удобней применять им, а не оператору, поставщику, торговому или вообще на английском, при этом "Проект" знает сам в каких наименованиях кому печатать (выдавать на экран)! И при этой или подобной фиче вы тоже добавите в главную форму переключателе, типа "выводить наименования по тому-то, по этому-то"? Хрень! А с этим смешным гридом я могу реализовать данную систему максимум за пол-дня, при этом возможность выбора распространится на ВЕСЬ проек (везде, где используется данный грид). Эта фича тоже требует корректировки на лету предложения СЕЛЕКТ.
Корректировка предложения ВЕР требуется для отображения/скрытия Устаревших данных, что опять же регулируется из грида. И вообще, в самом гриде висит Гридная панель инструментов (которая может настраиваться от одного Целевого грида к другому) и фич в которой оч много, и многие чего-нить требуют от источника записей или как-либо его модифицируют.
Тоже самое в отношении ОРДЕР БАЙ (не буду развивать, куда нафик еще?).
Т.е. мне НАДО модифицировать СЕЛЕКТ, ВЕР и ОРДЕР БАЙ!

Далее... (не устали читать?:)
> Ну допустим, передадим мы все эти параметры без проблем, а кто гарантирует, что мы на истином пути?
Я для себя (и ни для кого более) гарантирую, что я на истинном пути, ибо сейчас строится удобный и гибкий (универсализация ) программный интерфейс к УЖЕ РАБОТАЮЩЕЙ системе, которая хорошо себя показывает.!

>И еще, если универсальность, то как колдовать над сохраненным запросом?
Выше ответил - через создание запроса над запросом, не самый эффективный вариант, но в качестве альтернативы подойдет.

для Владимир Саныч
>Это оттого, что автор вопроса не выплюхнул перед нами весь проект. И, кстати, правильно, что не выплюхнул.
А вот это уже, где-то, обыдно... Да? :(
Вы же не видели реализации, не работали по такой системе ограничения предоставляемых пользователю данных. Вы же не знаете, как прутся операторы в момент, когда торговые начитывают им заказы с бумажных прайсов - оператор в качестве ГРУППЫ открывает накладную на отгрузку товара, а в качестве ИСТОЧНИКА ДАННЫХ ДЛЯ ГРУППЫ - электронный вариант печатного прайс-листа, по которому начитывается заказ Торговым, и, т.о. оператор не ищет нужный товар в этих самых 15 000 записях, а просто пролистывает на экране электронный прайс (один-в-один такой же, как и у Торгового) и тащится от отсутствия необходимости вбивать названия товаров при поиске. А еще... Да я еще гору могу примеров по юзабилити выложить, но, сдается мне, нахр это здесь никому не нужно. Да и мне тоже, вообщем-то...

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

Всем спасибо!
//пошел спать, хоть и рано еще... Выпил потамушта... (т.е. имеется в виду, что если кто-нить осилит всю эту чушь прочитать, да еще и ответить, то раньше завтре-послезавта (может быть) ответить не смогу...) Хотя, это и так никому нахр... се... спать...

Блииииииииииин...

Владимир Саныч, эт я извиняюсь! То ли слишком долго воял свой пост, то ли даже не заметил (по пьяни) наличия второй страницы в топике, в результате чего не увидел вашего: "Я имел в виду, что форум не предназаначен для того, чтобы мы тут всей толпой писали все системы друг друга. Человек задал конкретный вопрос, мы на него ответили, этого должно быть достаточно." Эта фраза, конечно, не оставляет места для моей, как оказалось, глупой и необоснованной "надутости".
Извиняюсь еще раз. Надеюсь, что поймете...

з.ы. по поводу 10 24 ... Один программер объясняет другому задачку: "Ну предположим у тебя 200 яблок... Не, возьмем 2 56 для ровного счета..." :)

:)
>Только осталось, чтобы V. Motchulsky не пошел бить нас обоих. :^)
Да неееее... ГОСТЬ так с ПРОПИСАННЫМИ жильцами обойтись не сможет :)

Ага... Натыкался на его посты двухгодичной давности, что достойно уважения само по себе... Просто обыграл ситуацию :)
з.ы. щаз за оффтопик мороженого лишат

в сторону:
э-т-о-б-ы-л-о-к-р-у-т-о...
Млин... На дуэль, што ли, его вызвать и прославиться так, как прославился Мартынов?

для вадя:
>писатель ....
Не... Графоман :)

>твои эпистолярные офтопики трудно читать
Косвенно, я пояснил, почему так мелко - перечтите все и возможно тоже поймете :) Да и кроме того, ежли б все это нормальным шрифтом, то у Вас лифт на скролбаре исчез бы

>ты уж ежели пишешь так чтоб хотяб у добно было читать...
ЁпрстУфхцч Ну дык если не у добно, тык и не читайте! Главное ведь ни как, а что! Я, вон, и на англицком доки читаю, хотя и чертовски не удобно, знаете ли. А недавно ходил на одну пагу, так там вообще на русском в перемешку с ивритом писано было, и ничего, не умер :) И, опять же, лично мне, было бы куда интересней узнать мнение не о "как", а о "что". Кстати, есть один трик: копируете текст в Ворд, увеличиваете как хотите и наслаждаетесь :) Но это только в случае, если Вам действительно интересно.

И, вадя, не обижайтесь на стёб, ибо я либо обижаюсь (когда пьяный), либо стебаюсь и/или делаю выводы (когда трезвый). Сейчас я трезвый. И лучше, имхо, дружеский стеб, чем недружеские выводы.

И вообще, вадя, это все V. Motchulsky виноват! Все притензии к нему! Раскрутил топик на две страницы и исчез... :)

Имхо, топик умер уже, топик в архив надо. Голосование через данный же топик