![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
откат изменений в БД
Александр_2012 © (2014-03-21 15:02:00)Добрый день.
Подскажите как откатить изменения в таблице БД после того, как отработан Post. Правильность заполнения основной таблицы БД проверяется с помощью SQL-запросов, прописанных в отдельной таблице. Но для того чтобы запрос отработал необходимо, чтобы данные были занесены в основную таблицу, т.е. метод Post отработал. Но если обнаружена ошибка в заполнении необходимо откатить изменения. Как это сделать?
turbouser (2014-03-24 11:36:00) [41]А что мешает вставлять данные в ХП? Там же и все проверки реализовать
Dennis I. Komarov (2014-03-24 11:33:00) [42]
> Это если delphi-прогеру крупно повезло, и в конторе есть
> специально выделенный db-прогер. Но так далеко не всегда
> и не везде
А тогда и нечего на Оракуль смотреть :)
> У меня на нескольких вкладках визуализируется порядка сотни
> полей БД. Если использовать Edit, то при пролистывании БД
> придётся написать довольно большой фрагмент кода, который
> будет обновлять информацию во всех Edit-ах.
И кому нужна такая визуализация? Информация должна отображаться когда необходима, а не чтоб было...
GUI - переделать;
DB-архитектуру - скорее всего тоже...
Александр_2012 (2014-03-24 11:28:00) [43]У меня на нескольких вкладках визуализируется порядка сотни полей БД. Если использовать Edit, то при пролистывании БД придётся написать довольно большой фрагмент кода, который будет обновлять информацию во всех Edit-ах.
>TField.OnSetText, OnValidate
Спасибо, подумаю, как это можно использовать для решения задачи.
clickmaker (2014-03-24 11:25:00) [44]> По-хорошему (правильному) delphi-прогер не должен задумываться
> о структуре БД
Это если delphi-прогеру крупно повезло, и в конторе есть специально выделенный db-прогер. Но так далеко не всегда и не везде
Dennis I. Komarov (2014-03-24 11:23:00) [45]
> Т.е. я правильно понял, что вместо DBEdit лучше использовать
> Edit и программно обрабатывать?
Не важно откуда будет браться ин-фа. По-хорошему (правильному) delphi-прогер не должен задумываться о структуре БД. В БД должен быть реализован интерфейс для добавления некой конечной сущности (документ, проводка, списание со склада и т.п.) в виде хранимой процедуры.
Данные проверил, передал в хранимку, получил результат...
clickmaker (2014-03-24 11:20:00) [46]> вместо DBEdit лучше использовать Edit и программно обрабатывать?
ну это уже от конкретной задачи зависит. Иногда лучше. Но и с DB-версиями можно валидацию делать. Н-р, TField.OnSetText, OnValidate
Александр_2012 (2014-03-24 11:16:00) [47]Dennis I. Komarov ©
> Да и на SQL метод Post никто не отменял.
Неточно выразился, хотел сказать у компонентов, работающих с SQL, т.е. OraQuery.
> которые оператор набрал в DBEdit-ах,
Вот их и надо выбросить первым делом.
Т.е. я правильно понял, что вместо DBEdit лучше использовать Edit и программно обрабатывать?
Dennis I. Komarov (2014-03-24 11:02:00) [48]
> Изменил OraQuery на OraTable
Вот он волшебный метод...
> Да и на SQL метод Post никто не отменял.
Чего-чего?
> которые оператор набрал в DBEdit-ах,
Вот их и надо выбросить первым делом.
Есть хранимые процедуры, пакеты... Читай про них...
А проверка лабуды, которую хотят внести в БД должна быть до внесения. Нечего всякий мусор туда тащить...
Александр_2012 (2014-03-24 10:50:00) [49]clickmaker ©
Хороший вопрос. А как? Подскажите. Разве можно выполнить SQL-запрос к таблице, пока данные в неё не занесены? В смысле запрос-то сделать можно, только он вернёт информацию о ранее внесённых данных, а не о тех, которые оператор набрал в DBEdit-ах, но ещё не подтвердил. Так ведь?
clickmaker (2014-03-24 10:44:00) [50]> Запросы типа: select Count(*) from table1 where pole1=1
> and pole2<>5
а почему бы не делать эти проверки до внесения данных?
Александр_2012 (2014-03-24 10:40:00) [51]clickmaker ©
Есть зависимость между значениями разных полей в основной таблице. Эта зависимость устанавливается распоряжениями руководства и может изменяться. Поэтому в отдельной таблице есть запросы позволяющие проверить правильность заполнения основной таблицы. Сейчас эта проверка производится на BeforePost, что неверно, т.к. введённых данных в таблице ещё нет и SQL-запрос вернёт ошибку (ошибки). Поэтому приходится как-бы дважды делать сохранение данных. Первый раз чтобы занести данные в таблицу, второй раз чтобы фактически сделать проверку. (Запросы типа: select Count(*) from table1 where pole1=1 and pole2<>5. Т.е. проверка, если pole1=1, то pole2 должно быть равно только 5. Если count(*) вернёт значение>0, значит есть ошибка)
Inovet ©
Сначала использовал OraQuery, но столкнулся с ситуацией, что когда в каком-нибудь поле забиваешь значения (надо оставить значение пустым), то при сохранении выскакивала ошибка о недопустимости значения, хотя в таблице все поля, кроме ключа, могут иметь значение "пусто". Изменил OraQuery на OraTable и проблема ушла. Да и на SQL метод Post никто не отменял. Буду рад подсказке как реализовать требуемую проверку без Post или с ним.
clickmaker (2014-03-24 09:51:00) [52]> с помощью SQL-запросов, прописанных в отдельной таблице
это как?
Inovet (2014-03-24 09:48:00) [53]> [4] Александр_2012 (24.03.14 09:25)
Какой тогда ещё метод Post, если есть специальный язык - SQL называется, в нём много чего есть вообще, а уж в Оракле и ещё больше. А в частности всё это делается в рамках транзакций. Не надо пользоваться всякими TTable.
Александр_2012 (2014-03-24 09:25:00) [54]Oracle
Inovet (2014-03-21 15:58:00) [55]> [2] Александр_2012 (21.03.14 15:14)
> А как задействуется механизм транзакций?
А БД какая скажешь наконец?
Александр_2012 (2014-03-21 15:14:00) [56]Есть ряд правил заполнения основной таблицы, причём они могут изменяться, поэтому проверка правильности вынесена в отдельную таблицу. Поэтому просто не представляю как изменить программу. А как задействуется механизм транзакций? Можно пример или ссылку?
RWolf (2014-03-21 15:06:00) [57]задействовать механизм транзакций используемой БД.
хотя, подозреваю, тут архитектуру приложения чинить надо.