Ну подскажите, млин, плз., млин, как мне, млин, передать, млин, эти гребанные, млин, параметры, да?!!!

Имеем Public Function в классе, которая принимает один параметр:
- либо имя сохраненного запроса (строковое значение);
- либо расчлененный на предложения текст запроса (SELECT, FROM, и т.п.), т.е. несколько строковых значений.
Если функция принимает имя сохраненного запроса , то никаких особенных действий не производится - параметр передается дальше по цепочке и все. А вот если передается сам текст запроса, то функция над ним колдует - над предложением СЕЛЕКТ отдельно, над ФРОМ - отдельно, над ОРДЕР БАЙ - отдельно и т.п.
Т.е. я не могу (не хочу) передавать текст запроса в одной строковой переменной, ибо придется устраивать синтаксический анализ, что займет как машинное время (на анализ), так и мое (на творение нетленного кода).
В итоге, создал пользовательский тип, где и перечислил несколько строковых переменных, призванных хранить предложения запроса по отдельности, но, мля, передать в функцию не могу, ибо параметр функции делаю Variantом (ну чтобы можно было передать либо строковую переменную с именем сохраненного запроса, либо передать переменную с пользовательским типом), а эта падл?ка пишет, что нельзя передавать пользовательский тип через Вариантовую переменную!!! (см.примечание)
Ну и что мне теперь, в принимающую функцию два параметра вставлять - один для имени а второй для текста запроса?! Или в пользовательский тип добавлять "ИмяСохраненногоЗапроса", наряду с "Селект", "Фром"?! Передавать через объект (класс)?!!! Через массив?!!!!!!!
Да еще и все это умножить на 2, ибо передаются данные сразу о двух запросах! :( Да еще и с кодом этим другие программеры работать будут :(((((

Как ни кручу - хрень, достойная стенда "Так делать не красиво " получается!
F1!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

з.ы. и пжалста, не надо "нахр тебе это надо", ибо сам не знаю, нахр?н мне все это надо вообще, мля...

ПРИМЕЧАНИЕ (Ошибка компиляции):
Only public user defined types defined in public object modules can be used as parameters or return types for public procedures of class modules or as fields of public user defined types

This error has the following cause and solution:
You attempted to use a public user defined type as a parameter or return type for a public procedure of a class module, or as a field of a public user defined type. Only public user defined types that are defined in a public object module can be used in this manner.

2000-ный...
Млин, могу десяток способов привести, как это можно сделать, если повыпендриваюсь, то еще десяток, а выбрать, поверишь, не могу, мля :(

Сделаем через класс...
Псиб за выбор :)

А потому что Optional совместно с пользовательским типом использовать (во всяком случае в а2000) незя (см. Ошибка компиляции).

Уже сделал через класс. Хотя, конечно, не очень то красиво получается - для того чтобы передать расчлененную конструкцию запроса необходимо создать объект. Да к тому же и еще один модуль класса добавился (не очень то и нужный). Но... но более "красивого" решения пока не вижу. А?

з.ы. ПарамАррэй тоже не подходит, т.к. функция принимает данные сразу по 2-м запросам и разобраться кто-есть где и от кого будет оч.сложно. Есть вариант с именованными аргументами, но опять же, одни головняки :(

Ошибка компиляции:
Invalid optional parameter type

Not all Visual Basic types are permitted for Optional parameters. This error has the following causes and solutions:

A parameter is defined with an invalid data type.
For example, you can't have an Optional parameter of user-defined type. You may be able to accomplish your goal using an array of Variant type, since the elements of an array of Variant can store data of different types.

>О Боже мой!!!
Млин, Саныч, ну кто-то же должен веселить народ

>Обычный String тут, по-моему, в самый раз.
Ну тады, держитесь
Передайте, пжалста, в качестве описания первого сохраненного запроса его имя, а в качестве описания второго - его конструкцию, при этом я вам предоставляю метод класса, который (по вашему) будет выглядеть так:

Object.DetermineRecordSource( [FirstSavedQueryName As String], [FirstSQL_BeforeSELECT As String], [FirstSQL_SELECT As String], [FirstSQL_FROM As String], [FirstSQL_WHERE As String], [FirstSQL_GROUPBYAndHAVING As String], [FirstSQL_ORDERBY As String], [FirstSQL_AfterORDERBY As String], [SecondSavedQueryName As String], [SecondSQL_BeforeSELECT As String], [SecondSQL_SELECT As String], [SecondSQL_FROM As String], [SecondSQL_WHERE As String], [SecondSQL_GROUPBYAndHAVING As String], [SecondSQL_ORDERBY As String], [SecondSQL_AfterORDERBY As String] )

(естественно, все параметры - Оптионал, просто не знаю как отреагирует форум на квадратные скобки, эдакие "теги" :)

Лично если бы мне пришлось работать с таким "программным интерфейсом" к классу, то я бы писал для себя надстройку, в которую и передавал бы все следующим образом:
Object.DetermineRecordSource(FirstQuery as Variant, SecondQuery as Variant)
где в Variant пихал бы либо имя запроса, либо структуру, описывающую онный, что, собстна, и пытаемся сделать...

Есть разница? ;)

з.ы. В третьем дубле, пжалста, на пальцах, если можно

для Владимир Саныч:
>Или по-другому: структура, одна и та же для обоих случаев, и пустые стринги в лишних полях в случае имени запроса.
Ни-фи-га не понял (говорю же, клинит уже... или вообще, по жизни:) Т.е. я должен сделать так:
Object.DetermineRecordSource(ИмяСохрЗапроса, , , , , , , , , , "SELECT то-то и то-то", "FROM оттудова с джойном с тем-то", "WHERE то-то равно этому-то", , "ORDER BY так-то") ?!!!
Млин... Убил бы себя! :)

для V. Motchulsky
>В чем ОСНОВНАЯ идея?
Я не очень догнал (см. "для Владимир Саныч" про "клинит":) какой уровень основной идеии имеется в виду.
Вобще-то, основная идея в топике - как передать классу два SQL-запроса - либо уже имеющийся сохраненный, либо динамически формируемый...
Зачем либо сохраненный либо формируемый? Ну дык... хм... Универсальность, будь она неладна, и расширение свобод программеров (и так постоянно отнимают, вон, даже через Вариант передать собстный тип не дают:). Хотя, попробую объяснить поподробней, но тока шобы враги не видели

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

ну вот, пока писал уже топик обновился...
для Владимир Саныч
Вариант от 13:57 пробовал. Не подходит по той простой причине, что
параметры в функции должны быть не обязательными, при чем оба! Т.е.
может быть передан первый запрос без второго, может быть наоборот.
При этом Оптионал совместно с пользовательским типом не прокатывает...
Все-таки, пока через класс наверно...

Да не катит МойКласс.МойМетод(Optional ТоТо As MeType , Optional ТоТо2 As MyType )!
То есть не возможно будет пропустить один из параметров!

Хотя, можно ведь и не пропускать, а просто передать пустую структуру (со всеми пустыми строками, что и будет расцениваться, как не переданный параметр...) Надо подумать...
Владимир Саныч спасибо за еще один вариант

з.ы.
>Боже мой дубль три,
Ну не видел я когда постил... :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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