Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Проверка логических условий при записи в БД


Страницы:   1 2

Александр_2012 ©   (2012-11-20 13:26:00) 

Доброго дня. Подскажите направление раскопок. Требуется организовать проверку допустимости вводимых пользователем значений. Итак, имеется основная таблица, которую заполняют пользователи. Имеется таблица-кодификатор, в которой прописаны допустимые значения для каждого поля основной таблицы. У меня на OnExit DBEdit-ов написана проверка этого соответствия и соответственно, если пользователь ввёл недопустимое значение, то получает сообщение о недопустимом значении и фокус ввода возвращается обратно. (Кстати, вариант тоже не очень удобный, т.к. при переходе с последнего редактируемого поля на DBNavigator для сохранения изменений событие  OnExit не происходит, поэтому буду рад информации как можно ввести данную проверку, чтобы она отрабатывала при любых условиях). И главная проблема: есть таблица в которой прописаны логические условия типа, если в таком-то поле стоит такое-то значение, то в другом поле может быть только такое значение. Если отработать Post, то потом с помощью SQL-запросов вполне можно проверить все логические условия для основной таблицы и при обнаружении ошибки перейти в режим редактирования записи, но это плохой вариант ибо кривая запись уже сохранена. Подскажите можно ли и как, если можно провести данную проверку до отработки Post.


Александр_2012   (2012-11-20 14:25:00) [21]


> OnBeforePost

Значения полей, введённые в DBEdit-ты до отработки Post в БД ещё не внесены. Так ведь? Т.е. написать запрос типа

select count(*) from bd where not (pole between 100 and 1000)
where id=идентификатору текущей записи и, если результат=0, то ошибки нет, где (pole between 100 and 1000)-логическое условие, а not добавляется программно

к  не сохраненным данным бессмысленно? Я написал утрированный запрос (такой вполне можно решить с помощью OnValidate), реально в нем присутствуют проверки на заполнение определёнными данными нескольких полей


AV   (2012-11-20 14:19:00) [22]

"тянуть словари на клиента" -с  таблицы-кодификатора все значения затянуть клиенту, пусть не вводит, а выбирает

в >>OnBeforePost проверить еще раз +логику


Плохиш   (2012-11-20 14:12:00) [23]

OnBeforePost


Александр_2012   (2012-11-20 14:12:00) [24]

Oracle


AV   (2012-11-20 14:10:00) [25]

СУБД какая?


Александр_2012   (2012-11-20 13:54:00) [26]

Можно, наверное, отфильтровать кодификатор таким образом, чтобы пользователь при заполнении очередного поля мог ввести только допустимые значения, но тут возникает другая проблема - значение одного поля могут зависеть от значений нескольких полей, допустим пользователь ввел неверное, но допустимое значение в одно из полей в результате другое поле получило список разрешенных значений, в котором нет нужного, т.к. пользователь ошибся в ранее введённом поле. Значит пользователь должен знать, какие поля влияют на допустимые значения текущего и искать где он ошибся с вводом, что неприемлемо.


> Либо тянуть словари на клиента перед редактированием либо
> запросы перед попыткой сохранения


Если можно расшифровать что означает "тянуть словари на клиента" и, "запросы перед попыткой сохранения" - для того, чтобы выполнить запрос к БД, значения должны быть в ней сохранены я правильно понимаю?


Медвежонок Пятачок   (2012-11-20 13:34:00) [27]

Классно вешать такую хрень на onExit дбэдита.
Особенно когда допустимые значение одного поля зависят от значений других полей.

за такое изуверство юзеры давно уже убивают разработчиков особо жестокими способами.

PS Либо тянуть словари на клиента перед редактированием либо запросы перед попыткой сохранения


Страницы:   1 2

Наверх

Титульная страница Поиск, карта сайта Написать письмо