Классная ситуация! Полдня с ней вожусь и наконец-то доперло

Делюсь результатом. Фишка в том, что когда ты передаешь параметр через ADO, ты выставляешь ему определенное значение (ноль, например). Если SELECT @id = ID FROM DOGOVOR WHERE NAME2 = @NAME2 не может выбрать ни одной строчки, то он НЕ УСТАНАВЛИВАЕТ @id в null. Следовательно, IF @ID is not null работает не так, как ты ожидаешь. Он честно проверяет условие 0 is not null и честно выходит из процедуры. Ситуация лечится добавлением в процедуру первой строки set @ID = null.

Несколько замечаний по всему остальному:

1. У тебя какое-то странное описание параметров. Мне даже удивительно, что твой код вообще работал. Для примера -
par1 = com1->CreateParameter(_bstr_t(L"@NAME2"), adVarChar, adParamInput, bstrVal.length(), bstrVal);
par2 = com1->CreateParameter(_bstr_t(L"@ID"), adInteger, adParamInputOutput, -1, _variant_t((long)0));
com1->Parameters->Append(par1);
com1->Parameters->Append(par2);

com1->Execute(NULL, NULL, 0);
То есть невредно именовать параметры - самому же удобнее будет.

2. Собственно о процедуре. Насколько я понимаю, тебе хотелось получить вот такое поведение - если строчка с таким именем в таблице есть, то вернуть ее ID, если нет, то добавить новую и вернуть полученный ID для новой строки. Так ? Ну, а теперь представь, что с твоей программой работает несколько пользователей и они разом ломанулись добавлять договора. Ты считаешь, что строки SELECT @ID = ISNULL(MAX(ID), 0) + 1 FROM DOGOVOR и INSERT INTO DOGOVOR (ID, NAME2) VALUES (@ID, @NAME2) выполняются строго одна за другой. На самом деле может быть ситуация, что двое практически ОДНОВРЕМЕННО сделали select, получили один и тот же ID, а потом попытались выполнить insert. Нельзя!

3. Запись return @id означает поведение процедуры как функции, то есть то же, что в сишнике будет return id. Для output параметра это бессмысленно. В твоем случае надо просто присваивать @id какое-то значение и выполнять return.

Спасибо за интересный пример! Мне аж понравилось

Ну, хорошо, что заработало.

Тогда еще чуть-чуть комментариев -

>3) Согласен, типа - нехорошо, но у нас везде так. И работает...
Это в корне неправильный подход! Законов Мерфи не читал? Оно не сработает именно в самый критичный момент. Кроме того, твой подход (понимаю, что неправильно, но исправлять не хочу) сильно попахивает дилетантством. Почему бы тебе не использовать identity? Если ты юзаешь SQL2K, то там есть крайне полезная штука SCOPE_IDENTITY, выгодно отличающаяся от @@identity тем, что возвращает последний @@identity в _данной_области_видимости_. Так что не возникнет никаких проблем с тем, что в триггерах делаются вставки в таблицы, где тоже есть поле identity и из-за этого в триггер верхнего уровня возвращается неправильное значение.

У меня прекрасно работают и OUTPUT PARAMETERS, и RETURN. Прежде, чем вопить "гады!", подумай, а может дело не в бобине? Легче всего сказать, что это баг производителя. Труднее критически оценить свой код. Напиши подробнее, в какой ситуации у тебя не работают параметры - я постараюсь подсказать.

Нет уж, нет уж Война еще не окончена!

1) Насчет identity присоединяюсь целиком и полностью, потому как уже довольно приличное время имею много любви с репликацией, преимущественно merge. В результате в качестве primary key везде использую поле типа uniqueidentifier и не жалуюсь. Вот в этом случае твой подход можно будет нормально использовать, заменив получение максимального ID + 1 на newid(). Тогда многопользовательская система будет работать правильно.
2) Параметр запустил, говоришь? Ну вот, а то - в Микрософте багов насажали, уроды... Сперва неплохо в зеркало смотреться

А насчет многих пользователей и неизбежной паузы между select и insert ты все-таки подумай, подумай... Пока идет "офисная" работа, все будет пучком. А вот когда возникнет надобность закачать МНОГО данных сразу через скрипты, а не ручками пользователя (архив обработать или там еще что...), то здесь геморрой и начнется - и ладно, если ты будешь рагребать получившуюся траблу, а то ведь можешь кого-нибудь еще подставить, если кто вместо тебя окажется. Непрофессионально мыслишь!