Раньше писал на ИСИ++, сейчас жизнь заставила на MSVC перелезть, отсюда вопросы про MFC:
1) Как выполнить хранимую процедуру?
2) Как сделать связку Master-Detail?
3) Как, вообще, получить курсор из более, чем одной записи, чтобы по ходу пьессы не подфетчивать?
4) Как получить что-либо типа BCB-шной функциональности, может библиотеки есть? (Это крик души, можно не отвечать)
Сервер: IB Database 6.0 + Intersolv ODBC драйвер. MSVC 6 Enterprise.
ЗЫ: Ох и быстро-ж привыкаешь к хорошему (эт я о простоте BCB).
- Вы знаете — жаль, просто по-человечески жаль Памелу Андерсон, которая никогда не сможет сыграть на баяне...
Здравствуйте Saddam, Вы писали:
S>Раньше писал на ИСИ++
А что это? Правда не понял...
S>1) Как выполнить хранимую процедуру?
Выполнить запрос вида
? = call MyStoredProc(?, ?)
Подробности — в подробном изучении работы с конкретным ODBC-драйвером.
S>2) Как сделать связку Master-Detail?
Тут я тоже не понял, что это значит...
S>3) Как, вообще, получить курсор из более, чем одной записи, чтобы по ходу пьессы не подфетчивать?
Курсор в принципе имеет записей от нуля до в общем бесконечности. Что означает "подфенчивать по ходу пьесы"?
S>4) Как получить что-либо типа BCB-шной функциональности, может библиотеки есть? (Это крик души, можно не отвечать)
Не знаю, есть ли библиотеки.
S>ЗЫ: Ох и быстро-ж привыкаешь к хорошему (эт я о простоте BCB).
От добра добра не ищут...
Хотел-бы сразу прпросить прощения у достопочтенной публики.... Не смотрел в статьях — большинство ответов там есть.
S>>Раньше писал на ИСИ++ TL>А что это? Правда не понял...
Пардрон, BCB.
S>>2) Как сделать связку Master-Detail? TL>Тут я тоже не понял, что это значит...
Собственно, это значит отношение "один ко многим" и его реализация в Inprise-продуктах.
Днло в том, что в Imprise-продуктах есть понятие Master DataSet и Detail DataSet, соответсвенно с угазанием ключевых полей по которым производится связка. Насколько я понял — здесь это можно реализовать толкьо парамсетризованными фильтрами.
S>>3) Как, вообще, получить курсор из более, чем одной записи, чтобы по ходу пьессы не подфетчивать? TL>Курсор в принципе имеет записей от нуля до в общем бесконечности. Что означает "подфенчивать по ходу пьесы"?
Это значит, что когда я делаю MoveNext, на сколько я понял, ODBC будет запрашивать сервер о следующем поле. Т.е. — 1операция=1запрос, что, как мне кажется несколько напряжно и для сети, и для сервера.
Появился еще один вопрос: есть-ли ODBC-драйвер для IB Database кроме Intersolv-а? А-то у меня не получилось его заставить работать в режимах кроме forvardOnly :(.
- Вы знаете — жаль, просто по-человечески жаль Памелу Андерсон, которая никогда не сможет сыграть на баяне...
Здравствуйте Saddam, Вы писали:
S>Пардрон, BCB.
Ну, я что-то такое подозревал...
S>Собственно, это значит отношение "один ко многим" и его реализация в Inprise-продуктах. S>Днло в том, что в Imprise-продуктах есть понятие Master DataSet и Detail DataSet, соответсвенно с угазанием ключевых полей по которым производится связка. Насколько я понял — здесь это можно реализовать толкьо парамсетризованными фильтрами.
Ну, я что-то такое подозревал. Насколько я понимаю, подобные механизмы все же реализованы средствами самих СУБД, точнее систем, которые собственно и служат "прослойкой" между самой БД и пользователем — это, например, Visual FoxPro или тот же Delphi. Или какой-то компонент ActiveX. А может я просто не знаю, как это реализовать средствами ODBC.
Суть, насколько я понимаю, в том, чтобы при перемещении по одному курсору другой динамически формировался в соответствии со связью "один ко многим". Интересно, конечно, как именно это реализовано в том же Delphi, но я, пожалуй, не вижу другого способа, кроме как каждый раз перегружать дочерний курсор. А может это все же уже реализовано: попробуйте копать в сторону библиотеки курсоров ODBC.
TL>>Курсор в принципе имеет записей от нуля до в общем бесконечности. Что означает "подфенчивать по ходу пьесы"? S>Это значит, что когда я делаю MoveNext, на сколько я понял, ODBC будет запрашивать сервер о следующем поле. Т.е. — 1операция=1запрос, что, как мне кажется несколько напряжно и для сети, и для сервера.
Вы поняли совершенно правильно: в обычном режиме MoveNext(...) будет идти к драйверу, а тот может к серверу и говорить "еще". Если больше нет — значит выбрали все строки курсора. Но можно сделать и несколько иначе: если Вам точно нужно загрузить весь курсор и Вы опасаетесь за излишнюю нагрузку на сеть, Вы можете заставить ODBC грузить записи блоками. Где смотреть? Один момент... Ну да: SQLSetSTMTAttr(...), а именно атрибуты SQL_ATTR_ROW_BIND_TYPE, SQL_ATTR_ROW_ARRAY_SIZE и тому подобные. В MSDN об этом сказано очень много и вполне доходчиво. Кстати, MFC также поддерживает этот механизм в своем CRecordset, правда, не на уровне Колдунов...
S>Появился еще один вопрос: есть-ли ODBC-драйвер для IB Database кроме Intersolv-а? А-то у меня не получилось его заставить работать в режимах кроме forvardOnly :(.
Это, скорее всего, к самому InterBase... Кстати, никто не знает каких-то официальных координат InterBase или как там сама контора называется?
Здравствуйте The Lex, Вы писали:
S>>Пардрон, BCB. TL>Ну, я что-то такое подозревал...
S>>Собственно, это значит отношение "один ко многим" и его реализация в Inprise-продуктах. S>>Днло в том, что в Imprise-продуктах есть понятие Master DataSet и Detail DataSet, соответсвенно с угазанием ключевых полей по которым производится связка. Насколько я понял — здесь это можно реализовать толкьо парамсетризованными фильтрами. TL>Ну, я что-то такое подозревал. Насколько я понимаю, подобные механизмы все же реализованы средствами самих СУБД, точнее систем, которые собственно и служат "прослойкой" между самой БД и пользователем — это, например, Visual FoxPro или тот же Delphi. Или какой-то компонент ActiveX. А может я просто не знаю, как это реализовать средствами ODBC.
TL>Суть, насколько я понимаю, в том, чтобы при перемещении по одному курсору другой динамически формировался в соответствии со связью "один ко многим". Интересно, конечно, как именно это реализовано в том же Delphi, но я, пожалуй, не вижу другого способа, кроме как каждый раз перегружать дочерний курсор. А может это все же уже реализовано: попробуйте копать в сторону библиотеки курсоров ODBC.
C другой стороны..... После некоторых размышлений получается, что при каждом Table->Next() в Inprise отрабатывает каждую деталь, то есть напрягает сервер. :( Может у MS это и разумнее, однако, напряжнее для меня ленивого :))).
TL>>>Курсор в принципе имеет записей от нуля до в общем бесконечности. Что означает "подфенчивать по ходу пьесы"? S>>Это значит, что когда я делаю MoveNext, на сколько я понял, ODBC будет запрашивать сервер о следующем поле. Т.е. — 1операция=1запрос, что, как мне кажется несколько напряжно и для сети, и для сервера. TL>Вы поняли совершенно правильно: в обычном режиме MoveNext(...) будет идти к драйверу, а тот может к серверу и говорить "еще". Если больше нет — значит выбрали все строки курсора. Но можно сделать и несколько иначе: если Вам точно нужно загрузить весь курсор и Вы опасаетесь за излишнюю нагрузку на сеть, Вы можете заставить ODBC грузить записи блоками. Где смотреть? Один момент... Ну да: SQLSetSTMTAttr(...), а именно атрибуты SQL_ATTR_ROW_BIND_TYPE, SQL_ATTR_ROW_ARRAY_SIZE и тому подобные. В MSDN об этом сказано очень много и вполне доходчиво. Кстати, MFC также поддерживает этот механизм в своем CRecordset, правда, не на уровне Колдунов...
Спасибо.
S>>Появился еще один вопрос: есть-ли ODBC-драйвер для IB Database кроме Intersolv-а? А-то у меня не получилось его заставить работать в режимах кроме forvardOnly :(. TL>Это, скорее всего, к самому InterBase... Кстати, никто не знает каких-то официальных координат InterBase или как там сама контора называется?
Здравствуйте The Lex, Вы писали:
S>>Собственно, это значит отношение "один ко многим" и его реализация в Inprise-продуктах. S>>Днло в том, что в Imprise-продуктах есть понятие Master DataSet и Detail DataSet, соответсвенно с угазанием ключевых полей по которым производится связка. Насколько я понял — здесь это можно реализовать толкьо парамсетризованными фильтрами. TL>Ну, я что-то такое подозревал. Насколько я понимаю, подобные механизмы все же реализованы средствами самих СУБД, точнее систем, которые собственно и служат "прослойкой" между самой БД и пользователем — это, например, Visual FoxPro или тот же Delphi. Или какой-то компонент ActiveX. А может я просто не знаю, как это реализовать средствами ODBC.
TL>Суть, насколько я понимаю, в том, чтобы при перемещении по одному курсору другой динамически формировался в соответствии со связью "один ко многим". Интересно, конечно, как именно это реализовано в том же Delphi, но я, пожалуй, не вижу другого способа, кроме как каждый раз перегружать дочерний курсор. А может это все же уже реализовано: попробуйте копать в сторону библиотеки курсоров ODBC.
Мужики, а что вы на ODBC зациклились? Эту технологию Микрософт перестал развивать, а значит, через пару лет она начнет вымирать понемногу. Сейчас вполне путевая вещь — ADO, она в отличие от ODBC оперирует не блоками данных, а объектами ActiveX. В ней заложена масса приятных мелочей, вроде иерархических наборов команд и т.п.
Здравствуйте Dale, Вы писали:
D>Здравствуйте The Lex, Вы писали:
D>Мужики, а что вы на ODBC зациклились? Эту технологию Микрософт перестал развивать, а значит, через пару лет она начнет вымирать понемногу. Сейчас вполне путевая вещь — ADO, она в отличие от ODBC оперирует не блоками данных, а объектами ActiveX. В ней заложена масса приятных мелочей, вроде иерархических наборов команд и т.п.
Ну и? Первое: для любой мало-мальски серъезной СУБД имеется ODBC-драйвер. Второе: как ни странно, ADO тоже позволяет соеденяться через ODBC. Третье: если уж на то пошло, то ADO — это надстройка над OLE DB...
Здравствуйте The Lex, Вы писали:
TL>Здравствуйте Dale, Вы писали:
D>>Здравствуйте The Lex, Вы писали:
D>>Мужики, а что вы на ODBC зациклились? Эту технологию Микрософт перестал развивать, а значит, через пару лет она начнет вымирать понемногу. Сейчас вполне путевая вещь — ADO, она в отличие от ODBC оперирует не блоками данных, а объектами ActiveX. В ней заложена масса приятных мелочей, вроде иерархических наборов команд и т.п.
По пунктам:
TL>Ну и? Первое: для любой мало-мальски серъезной СУБД имеется ODBC-драйвер.
Абсолютно верно, для своего времени ODBC была самой продвинутой технологией доступа к данным. По сути, единственная альтернатива библиотекам доступа, которые каждый производитель СУБД поставлял со своим детищем и которые были уникальны для каждой архитектуры. Вот только даже самые крутые технологии со временем устаревают, ничего тут не попишешь... Тем более что OLE/COM/COM+/DCOM/ActiveX/... , как бы их дядя Билли ни нахваливал, по-настоящему работоспособны и надежны стали совсем недавно, раньше проблемно было на них серьезные вещи делать.
TL>Второе: как ни странно, ADO тоже позволяет соеденяться через ODBC.
Нисколько не странно. Странно было бы, кабы наоборот (см. предыдущий пункт). Имея надежную, хорошо отлаженную и, главное, универсальную технологию доступа к данным, которая к тому же поддержана всеми серьезными производителями реляционных СУБД, глупо было бы не сделать туда лазейку. А лазейка эта — в трансляции ADO-шных операций над данными в ODBC и обратное преобразование результатов. Тем самым выигрывается время, пока поставщики сделают полноценные драйверы с поддержкой OLE DB. Сделают — возрастет эффективность, но пока и так работает.
TL>Третье: если уж на то пошло, то ADO — это надстройка над OLE DB...
Опять же никто не спорит, оно и в самом деле на то пошло. OLE DB — _низкоуровневая_ спецификация для интерфейса с сервером БД, а ADO оперирует с объектами _высокого_ уровня, удобными для прикладных программистов и прячущими от них довольно сложные и малоинтересные подробности интерфейса OLE DB. Хотя это на любителя, можно писать прямо для OLE DB. Пишут ведь люди на ассемблере... Хотя одни — по необходимости, другие — из кокетства, крутизну показать. Здесь ситуация примерно такая же.
TL>А как можно решить поставленную задачу на ADO?
Теперь от теоретических мудрствований — к конкретному делу. Насколько я помню, _поставленная задача_ — это просмотр первой таблицы, одним из полей которой является уникальный ключ, и выборка соответствующих записей из второй таблицы, которые ссылаются на этот ключ в качестве "foreign key"?
Если я правильно понял, в ADO такая операция делается на раз. Точнее, за несколько раз:)
1. Создать объект Connection
2. ---"--- два объекта Command (для выборки из первой и второй таблиц соответственно)
3. Указать первый Command в качестве родительского для второго
4. Выполнить метод Execute для первого Command
Это все! При перемещении курсора по первому набору записей второй модифицируется автоматически, для этого иерархия команд и придумана. По-моему, проще не бывает.
Здравствуйте Dale, Вы писали:
D>По пунктам: TL>>Второе: как ни странно, ADO тоже позволяет соеденяться через ODBC. D>Нисколько не странно. Странно было бы, кабы наоборот (см. предыдущий пункт). Имея надежную, хорошо отлаженную и, главное, универсальную технологию доступа к данным, которая к тому же поддержана всеми серьезными производителями реляционных СУБД, глупо было бы не сделать туда лазейку. А лазейка эта — в трансляции ADO-шных операций над данными в ODBC и обратное преобразование результатов. Тем самым выигрывается время, пока поставщики сделают полноценные драйверы с поддержкой OLE DB. Сделают — возрастет эффективность, но пока и так работает.
Не сделают: большинства и них уже просто нет в природе...
TL>>Третье: если уж на то пошло, то ADO — это надстройка над OLE DB... D>...OLE DB — _низкоуровневая_ спецификация для интерфейса с сервером БД, а ADO оперирует с объектами _высокого_ уровня, удобными для прикладных программистов и прячущими от них довольно сложные и малоинтересные подробности интерфейса OLE DB. Хотя это на любителя, можно писать прямо для OLE DB. Пишут ведь люди на ассемблере... Хотя одни — по необходимости, другие — из кокетства, крутизну показать. Здесь ситуация примерно такая же.
OLE DB и ADO — Assembler и C++... Что ж, может и так...
TL>>А как можно решить поставленную задачу на ADO? D>...
Здравствуйте The Lex, Вы писали:
TL>С этого и надо было начинать... Спасибо...
Звиняйте, дядьки, больше не буду, срочно исправляюсь! :))
В свое оправдание добавлю, что, поскольку автор первоначального вопроса переходит на MSVC, то нет необходимости даже создавать объекты Connection и Command, для этого есть графические инструменты, где все делается парой щелчков мышки. Более того, отбуксировав родительский Command в окно формы, автоматически создастся набор control'ов для навигации по базе.
Искренне Ваш,
Dale
D>Если я правильно понял, в ADO такая операция делается на раз. Точнее, за несколько раз:) D>1. Создать объект Connection D>2. ---"--- два объекта Command (для выборки из первой и второй таблиц соответственно) D>3. Указать первый Command в качестве родительского для второго D>4. Выполнить метод Execute для первого Command D>Это все! При перемещении курсора по первому набору записей второй модифицируется автоматически, для этого иерархия команд и придумана. По-моему, проще не бывает.
По пунктам это хорошо, а для тех кто в танке можно разжевать :)
Что и как передать в метод Execute,
где указать первый Command в качестве родительского для второго
Здравствуйте SAndrey, Вы писали:
SA>По пунктам это хорошо, а для тех кто в танке можно разжевать :)
SA>Что и как передать в метод Execute, SA>где указать первый Command в качестве родительского для второго
Во-первых, вряд ли тут уместно переписывать документацию из MSDN, а уж там все это охвачено на 200%. Другое дело, если есть конкретный вопрос...
Во-вторых, работая в среде MS Visual Studio, просто грех не воспользоваться графическими средствами для создания объектов ADO, писать код приходится по минимуму. А там в визарде при создании объекта Command на закладке Relation просто можно выбрать "Relate to a Parent Command Object" и т.д. Потренировавшись со средствами RAD, можно уже и самому непосредственно с объектами поработать, попроще будет.
В-третьих, господам танкистам :) настоятельно рекомендую почитать книгу Роджера Дженнингса "Руководство разработчика баз данных на Visual Basic 6". Пусть название не отпугивает, книга на самом деле в основном по современным технологиям доступа к данным, а Basic — только как язык для реализации примеров.Хотя,если честно, я бы на VB свысока не поглядывал, вполне достойный инструмент при работе с ADO.
Здравствуйте Dale, Вы писали:
D>В-третьих, господам танкистам :) настоятельно рекомендую почитать книгу Роджера Дженнингса "Руководство разработчика баз данных на Visual Basic 6". Пусть название не отпугивает, книга на самом деле в основном по современным технологиям доступа к данным, а Basic — только как язык для реализации примеров.Хотя,если честно, я бы на VB свысока не поглядывал, вполне достойный инструмент при работе с ADO.
А еще точнее: VB — это вполне достойный инструмент создания пользовательского интерфейса БД...
Благодарствую за ответ.
Господа не судите строго, я за VC сел совсем недавно,
а до этого много времени писал на Delphi, где как вы понимаете таких
вопросов не возникало :о( или :о).
Всвязи с этим есть желание со всем разоброаться.
>>А там в визарде при создании объекта Command на закладке Relation просто можно >>выбрать "Relate to a Parent Command Object" и т.д. Потренировавшись со средствами >>RAD, можно уже и самому непосредственно с объектами поработать, попроще будет.
Отсюда вопрос , что это за визард, где можно создать объект Command и на закладке Relation выбрать "Relate to a Parent Command Object" ?
И второй вопрос — возможно ли в VC (средствами к-л библиотеки) сваять приличный отчет?
D>Опять же никто не спорит, оно и в самом деле на то пошло. OLE DB — _низкоуровневая_ спецификация для интерфейса с сервером БД, а ADO оперирует с объектами _высокого_ уровня, удобными для прикладных программистов и прячущими от них довольно сложные и малоинтересные подробности интерфейса OLE DB. Хотя это на любителя, можно писать прямо для OLE DB. Пишут ведь люди на ассемблере... Хотя одни — по необходимости, другие — из кокетства, крутизну показать. Здесь ситуация примерно такая же.
Ну если пишешь сам провайдер, то почему бы и не работать с ним на прямую :)
тем более что затраты (в строчках кода) получаются соизмеримыми с кодом для работы с ADO из VB
Не вериться, да?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте Коваленко Дмитрий, Вы писали:
КД>Ну если пишешь сам провайдер, то почему бы и не работать с ним на прямую :) КД>тем более что затраты (в строчках кода) получаются соизмеримыми с кодом для работы с ADO из VB КД>Не вериться, да?
Нет, почему же... Я вообще доверчив от природы, а уж против авторитета MSDN и вообще не попрешь... А их мнение по данному вопросу однозначно: ...The solution to accessing different kinds of data throughout the enterprise is to use OLE DB as a data provider and ActiveX® Data Objects (ADO) as the data access technology... (статья "Making Data Access Easier")
Так что по поводу интерфейса провайдеров предмета для спора не вижу. Другое дело, так ли уж часто мы их пишем... А для готовых — сам бог (посредством MSDN) велел ADO юзать.
Здравствуйте Dale, Вы писали:
D>Здравствуйте Коваленко Дмитрий, Вы писали:
КД>>Ну если пишешь сам провайдер, то почему бы и не работать с ним на прямую :) КД>>тем более что затраты (в строчках кода) получаются соизмеримыми с кодом для работы с ADO из VB КД>>Не вериться, да?
D>Нет, почему же... Я вообще доверчив от природы, а уж против авторитета MSDN и вообще не попрешь... А их мнение по данному вопросу однозначно: D>...The solution to accessing different kinds of data throughout the enterprise is to use OLE DB as a data provider and ActiveX® Data Objects (ADO) as the data access technology... (статья "Making Data Access Easier") D>Так что по поводу интерфейса провайдеров предмета для спора не вижу. Другое дело, так ли уж часто мы их пишем... А для готовых — сам бог (посредством MSDN) велел ADO юзать.
Вообщем то я тоже против ADO ни чего не имею. Даже наоборот, люблю это дело под VBA+Excel. Но для работы из С++ сваял собственный набор классов. Тем более что переезд осуществлялся с аналогичной библиотеки, но для API InterBase (а та ушла внутрь провайдера :-) ). Опыт в общем был.
А так пришлось бы делать надстройку над ADO, которая была бы "всего лишь" надстройкой. Мой менталитет был против, особенно при том, что первые версии ADO по бешенности были соизмеримы с самим провайдером :).
По поводу готовых провайдеров. Эти мерзавцы из MS их только через ADO и тестируют. Причем ADO "своих" распознает и более тесно с ними сотрудничает. Это я про MSDASQL. А последний просто падал как дите, если передавать параметры не в VARIANT формате. И это фундамент технологии доступа! Надеюсь что сейчас все стало на места, но проверять это некогда.
Тут вот вспомнил про ATL OLEDB — самым наглядным образом продемонстрированно отвращение Microsoft к своему детищу под названием OLEDB. Уроды...
PS. Не, ну я просто балдею от сервиса этого ... слово сайт для него уже маловато :)
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
