>Через выходной параметр процедуры и код ее завершения не хочу, потому как неохото лишнюю процедуру писать
Это Вы, батенька, напрасно... Количество "клиентских" запросов нужно вседа минимизировать и использовать SP где только можно.

зы: особенно, если "хотите быть круче"

ИМХО, это изврат. ЗАЧЕМ перегружать бд-клиента той логикой, которую можно возложить на SQL-Server??? А если клиента пишет, скажем веб-дизайнер, имеющий мин. представления о БД? Или наоборот бд-девелопер не шарит веб-дизайне? (веб-прил. - это только один из возможных примеров). Или, скажем, придется все переделывать под какой-нить оракль? К тому же, вдруг этот хренов дельфи когда-нибудь Славу достанет, и он закинет его подальше вместе со всеми этими TTable и TQuery в аасортименте ? "Тонкий клиент" - он хоть даже и на срваке выполняется и явл. только клиентом SQL-Server'a - все равно должен быть чем тоньше, тем лучше (про "конечных" клиентов я вообще молчу).

//imho

// опять же ИМХО
Отталкиваясь от собственного опыта могу сказать сл.:
1. Редактировать записи в гриде - последнее дело. Гораздо более удобным (для всех) оказывается такой путь: грид служит только для навигации по сету. При перемещении грид-курсора, который выделяет всю записть, а не отдельные поля, в соответствующих edit-control'ах, расположенных, скажем, под гридом, отображаются значения полей. Юзер может
а) Добавить новую запись, введя новые значения в контролы. При этом вызывается соотв. SP с параметрами типа SP_AddNewHrenovObject , которая вернет новый PK.
б) Изменить текущую запись, откорректировав содерж. контролов и нажав кнопку [Изменить]. Вызовется SP_ChangeHrenovObject, которой в кач. парам. передается ID тек. записи.
в) Ну и удалить тек. зап. соотв. выз. SP_NafigHrenovObject + 1000 предуп. типа "Вы действ... "

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

2. Эсли кн-нить опровергнет вышеизложенное (частично или полностью) буду очень признателен.
Но не так:
HrenovSet = OpenRecordset("SELECT * FROM tblHrenovaTablitsa", DB_DYNASET | DB_NEVERMIND | DB_HOVAISAHTOMOZJET)
HrenovSet.Fields(1).Value = "It wroks!!!"
и т.п.

>У меня в БД 100 таблиц. Для каждой процедуру?

Слава, ну ты же не поленился создать 100 таблиц...

>И еще. Ценность процедуры конечно велика, но надо точно разобраться где. Если мы хотим вставить запись в таблицу, то вобщем все равно, отправим ли мы с клиента exec Proc или insert... Согласитесь, что трафик в этих случаях почти одинаков.

Дело здесь не столько в трафике, сколько в логике, а точнее в стратегии. Клиент НЕ ЗНАЕТ о том, что есть какие-то таблицы, инсерты и т.п. Он (клиент) оперирует с объектами, которые ему необходимо хранить в некотором хранилище. Чем меньше он знает о внутренней организации оного, тем лучше. И пусть в SP один единственный инсерт - это не важно. Совокупность хранимых процедур это интерфейс взаимодействия бд-клиента и бд-сервера (в смысле бд-серверной части приложения). Бд-клиент не должен лезть в кишки бд-сервера в обход установленного интерфейса.
Получается такая структура:

Кон. клиент <-- тут все ясно --> бд-клиет <-- механизм SP --> бд-сервер <-- SQL etc... --> конкретный бд-серв. (в частности MS SQL Server).
либо:
бд-клиет он же кон. клиент <-- механизм SP --> бд-сервер <-- SQL etc... --> конкретный бд-серв.

при такой оганизации изменение логики одного звена не повлияет на оснальные звенья

2 Павел:
извините за некоторую категоричность, я не хотел, чтобы это все так прозвучало...
<ИМХО>
С пользователями отличный пример. Интересный. Я воплощал так:
Основная прога работает на серваке, по сети конечным юзерам гоняются только интерфейсы.
Система безопасности SQL Server не используется (все конекты от имени sa).
Есть спец. база пользователей, где хран. пользователи, группы, экшины и разрешения.
Механизм:
Юзер сервлету: я такой-то юзер, хочу добавить объект
Сервлет - бд-серверу : usr_ID хочет выполнить ActionName
бд-сервер - сревлету : permit = 0
сервлет - юзеру : низьзья
или
бд-сервер - сревлету : permit = 1
сервлет - бд-серверу : exec SP_ActionName
бд-сервер - сревлету : result = 1
сервлет - юзеру : все ништяк

Получается, что каждый общается на своем языке. В итого Юзер не будет падать в обморок от наворотистых ругательств, всплывающих из недр SQL Server'а, и, следовательно не будет вам звонить с претензиями типа "Я тут все правильно делаю а оно глючит и ваще..."

Кстати, настройка разрешений и юзеров - это те же экшины, которые разрешены админу данного приложения.

А курсор - хоть серверный, хоть клиентский - он и в Африке курсор. И лучше чем в BOL о нем врядле скажешь
</ИМХО>

а @@identity ?

2 Genady:
Вот и я не нашел... Как и не нашел ответ на такой вопрос: нужно ли осуществлять блокировки внутри хранимых процедур?