В общем - то, вопрос в перехвате исключений при инсерте.
Я инсерт запихнул в ХП, чтобы там when-ом их разбирать.
1) если такой подход не криминален, то как в ХП передать вводимую строку из DBGrid-а?
2) если так неправильно, то как надо организовать перехват исключений?

grid.datasource.dataset.fields[0].As
соответственно, ХП должна в параметрах иметь все необходимые для заполнения полей

В гриде я заполняю НОВую строку (* - справа :)).
Как эти значения передать ХП, чтобы реальный инсерт в dataset сделать в ней?

> Как эти значения передать ХП, чтобы реальный инсерт в dataset
> сделать в ней?

датасет на клиенте, ХП на сервере
ты не можешь сделать инсерт в ХП, чтоб это бумерангом вернулось в датасет
только переоткрытием датасета после выполнения ХП

имхо, ты не понимаешь, чего хочешь, оттого такие перректальные иеи

> Drowsy   (10.09.08 16:16)
>
> В общем - то, вопрос в перехвате исключений при инсерте.
>

try.. except

> Я инсерт запихнул в ХП, чтобы там when-ом их разбирать.

триггеры чем не угодили?

> Как в ХП передать вводимую строку из DBGrid-а?

Правильной настройкой DBGrid-DataSource-DataSet,...

Ситуация банальная и с которую, конечно, каждый опытный "базник"
решил. Мне это пока не по уму...
В базе есть таблица с ограничениями на значения полей и внешними
ключами. Она через DataSource->DataSet связана с гридом.
При попытке "плохого" редактирования вываливаются
малопонятные пользователю сообщения.
Можно, конечно, в триггерах проверять соблюдение правил
таблицы и генерировать действия или свои сообщения,
но интереснее ведь организовать перехват внутренних
сообщений по их gdscode (на зря ведь все эти FK и Constrant -ы придуманы).
Я написал ХП

CREATE PROCEDURE NEW_PROCEDURE
as
begin
begin
INSERT INTO LOUT(
   CODE,
   Stad,
   Brod
)
VALUES(
   gen_id(GEN_LOUT_ID, 1),
   1,
   2

);

when gdscode check_constraint do
EXCEPTION check_exception;

when any do
  begin

     EXCEPTION any_exception;
  end

end

suspend;
end^

Вызываю её, щёлкая батон на форме.
Если корректные значения - записываются,
если нет - исключения перехватываются.

Теперь вопрос, как увязать манипуляции в гриде
и вызов этой ХП? Например, заполнил новую строку и хочу передать её
для записи в ХП.

Сильно не ругайтесь... :)

> заполнил новую строку и хочу передать её
> для записи в ХП


Для этого ХП должна принимать вх.параметры.
А у тебя они напрочь отсутствуют.

> В базе есть таблица с ограничениями на значения полей и
> внешними ключами. Она через DataSource->DataSet связана
> с гридом.При попытке "плохого" редактирования вываливаются
> малопонятные пользователю сообщения.

делай так, чтоб не было плохого редактирования
внешние ключи прекрасно разруливаются через dblookupcombobox, а ограничения на значения полей можно вбить в программу (или читать налету из БД), чтоб проверять до посылки в БД
тогда и никаких проверяющих ХП не нужно

Да, это понятно.
Просто казалось логичнее (и полезнее мне для понимания баз) попробовать сделать с перехватом исключений. Но, видимо, проще будет, как Вы
предлагаете, Правильный$Вася   (11.09.08 11:04) [8]

> Теперь вопрос, как увязать манипуляции в гриде
> и вызов этой ХП?


Надо чтобы вместо запроса
 INSERT INTO TableName(Fielld1, ..., FielsN) VALUES (:Fielld1, ..., :FielsN)
на сервер пошел запрос
 EXEC NEW_PROCEDURE (:Fielld1, ..., :FielsN)

У разных наследников TDataSet разные механизмы подмены стандартного поведения. Чьл исплдбзуешь ты - неизвестно.

> У разных наследников TDataSet разные механизмы подмены стандартного
> поведения. Чьл исплдбзуешь ты - неизвестно.


FibPlus1.5

type
 TTESTFORM = class(TForm)
   db: TpFIBDatabase;
   tr: TpFIBTransaction;
   dt: TpFIBDataSet;
   ds: TDataSource;
   DBGridEh1: TDBGridEh;
........
end;

>Drowsy   (11.09.08 11:17) [9]
>Просто казалось логичнее (и полезнее мне для понимания баз) попробовать сделать с перехватом исключений.

Логичнее всякий мусор ловить непосредственно на клиенте с помощью простой проверки обработчиками событий как грида (OnColumnExit), так и датасета (BeforePost,TFileld.SetText) с выдачей пользователю внятных сообщений о типе и объекте ошибки, нежели тащить всю эту дрянь по сети серверу и ждать от него каких-то исключений, которые затем все равно разбирать на клиенте.

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

> MsGuns ©   (11.09.08 16:15) [12]


> Проверка на сервере должна выполняться на те условия, которые
> от клиента скрыты или присутствуют неявно

Для этого для в ХП надо передать новые значения полей из грида для проверки их корректности. Так? Как "снять" из новой или отредактированной строки эти значения? Не могу найти в каком свойстве грида (или DataSet - a ?) они находятся?

> [11] Drowsy   (11.09.08 13:08)


см. TpFIBDataSet.InsertSQL

> Для этого в ХП надо передать новые значения полей из
> грида для проверки их корректности.

нет, ХП уже просто сохраняет данные и отлавливает найденные сервером проблемы
но это уже не проверки

>Не могу найти в каком свойстве грида (или DataSet - a ?) они находятся?

Текущая ячейка сетки TDBGrid.SelectedField.{Asxxx:Value}

Любое поле датасета TDataSet.{Fields[<Индекс>],FieldByName('<Имя поля>')}.Asxxx:Value}