Работа с MSSQL ч/з ADO и хранимки

Доброго времени суток, коллеги и все остальные.
Нужен Ваш добрый совет по следующему вопросу: есть ли в ADO механизмы, способные работать с базой посредством вызова разных хранимых процедур на сервере, реализованные в одном компоненте, наподобие такой как ADO.NET.

Или нужно работать ч/з ADOStoredProc, запрашивая select'ы и update'ы каждый раз явно вручную?

Заранее спасибо за конструктив...

0

1. Не вижу связи между ADOStoredProc и select'ами и update'ами
2. Что мешает использовать TADOQuery, прописывая в свойстве SQL стэйтмент типа

0

Попробую переформулировать вопрос.
Использование Query нежелательно, т.к. стоит задача строго разграничить права юзерам, которых со временем может быть много. Было решено выбрать метод, при котором все операции будут делаться через хранимки на серваке. Думаю далее всё понятно... Раздача прав и бла-бла-бла )

Так вот в ADO.NET для такого подхода есть всё что нужно и инкапсулировано это в одном компоненте(забыл уже как называется, что-то вроде ADOCommand). А вот в ADO в StoredProc я ничего подобного не нашёл.

По-этому ещё разок вопрос: можно ли такой подход реализовать на ADO?

0

обычно использовал хранимые процеуры в dbexpress но вот только что попробывал в ado. тоже самое

в компоненте ADOdataset в commandtype выбираем cmdStoredProc
затем в commandText выбираем имя хранимой процедуры, подставляем параметры вот вроде и все...

а вот по поводу ADOquery и прав пользователей... Ведь ADOquery использует соединение с БД adoConnection, которое логинется в БД под определенным пользователем. соответственно и все хранимые процедуры запущеные как написал SAMZ, будут выполняться под правами пользователя под каким был коннект к БД

1

Вопросы я формулирую ни к чёрту, по-этому попробую "на пальцах", может лучше получится:

1) Query не подходит, т.к. требуется дать права на таблицу, а мне нужно, чтобы user мог делать только то, что я ему разрешу и так, как мне это надо. Т.е. оптимально будет использовать хранимку.
2) Мне нужен компонент-потомок TDataSet, в котором была бы возможность назначить все 4-ре процедуры(select, update, delete и insert) одновременно, так как это сделано в ADO.NET.
Для чего? Для того, чтобы на клиенте (в приложении) работало правило 1 таблица --> 1 компонент для работы с ней. Иначе, чтобы использовать подход с ХП придётся все DML операции вызывать явно вручную да ещё и с помощью как минимум 4-х различных компонентов, позволяющих вызывать ХП. И получаемые данные обрабатывать тоже вручную, т.е. что-то вроде этого Edit1.Text := SPData.FieldByName('DATA').asString вместо того чтобы взять обычный DBEdit, подключить его к компоненту, обеспечивающему DML операции и не не думать о том, как синхронизировать данные на клиенте и на сервере.

Если опять коряво написал, не судите строго, коллеги. Очень жду Ваших советов и предложений

0

Сообщение от Чёрный Медведь при котором все операции будут делаться через хранимки на серваке

А по - вашему вот это
где выполняется?

Сообщение от Чёрный Медведь И получаемые данные обрабатывать тоже вручную, т.е. что-то вроде этого Edit1.Text := SPData.FieldByName('DATA').asString вместо того чтобы взять обычный DBEdit, подключить его к компоненту, обеспечивающему DML операции и не не думать о том, как синхронизировать данные на клиенте и на сервере

Да это просто каша какая-то! Что Вам мешает взять обычный DBEdit, подключить его к компоненту, обеспечивающему....?!
Добавлю к этому то, что мне известны очень опытные программеры, которые отвергают именно использование компонент прямого редактирования БД. Они предпочитают загружать данные в обычные едиты, редактировать и потом загружать и сохранять измения в БД.

1

Сообщение от Чёрный Медведь Мне нужен компонент-потомок TDataSet, в котором была бы возможность назначить все 4-ре процедуры(select, update, delete и insert) одновременно, так как это сделано в ADO.NET.

такое я встречал только в ado.net тут придется обходными путями (возможно через события beforinsert, befordelete и т.п. )

0

Сообщение от SAMZ Да это просто каша какая-то! Что Вам мешает взять обычный DBEdit, подключить его к компоненту, обеспечивающему....?!

Очень мешает тот факт, что DBEdit один штука, а операций, которые надо через него реализовать - 4! И если прикреплённый к нему DataSet их все не инкапсулирует, то как бы труба дело.

Сообщение от SAMZ Они предпочитают загружать данные в обычные едиты, редактировать и потом загружать и сохранять измения в БД

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

Добавлено через 1 минуту

Сообщение от slayer такое я встречал только в ado.net тут придется обходными путями (возможно через события beforinsert, befordelete и т.п. )

Похоже мысль донёс. Спасибо, это по теме

Добавлено через 4 минуты
Полагаю тему можно закрыть.
Отрицательный результат - тоже результат )

0

Сообщение от slayer в котором была бы возможность назначить все 4-ре процедуры(select, update, delete и insert) одновременно

Такое есть и широко используется в компонентах FIBPlus, Но это только для FireBird/Interbase. Кроме того такая реализация есть в BDE компонентах при использовании TQuery в режиме CashedUpdate совместно с объектом UpdateSQL, но тут другая проблема: BDE сегодня не рекомендуется к употреблению!

0

Я и не планировал пользовать BDE. Да, такой подход я видел ещё в ODAC'е. Это очень удобно. Сейчас приходится юзать ADO, вот я и решил спросить нет ли такой вкусности и в них. Похоже, не судьба )). Всем спасибо за ответы

0

Чёрный Медведь, ну если вы уже знакомы с одаками, то почему бы не поюзать мсдаки? по наборам свойств и функций очень похож на другие ДАКи... и работать с ним одно удовольствие

1

Сообщение от Lord_Voodoo Чёрный Медведь, ну если вы уже знакомы с одаками, то почему бы не поюзать мсдаки? по наборам свойств и функций очень похож на другие ДАКи... и работать с ним одно удовольствие

Это было бы очень удобно, но вот политика предприятия, в котором я чейчас работаю, ориентирована на ADO. К сожалению, никто не будет покупать DAC'и специально для меня, особенно если учесть, что все текущие проекты реализованы на ADO. Однако, за совет спасибо

0