откат изменений в БД

← →
Александр_2012 (2014-03-21 15:02) [0]

Добрый день.
Подскажите как откатить изменения в таблице БД после того, как отработан Post. Правильность заполнения основной таблицы БД проверяется с помощью SQL-запросов, прописанных в отдельной таблице. Но для того чтобы запрос отработал необходимо, чтобы данные были занесены в основную таблицу, т.е. метод Post отработал. Но если обнаружена ошибка в заполнении необходимо откатить изменения. Как это сделать?

← →
RWolf © (2014-03-21 15:06) [1]

задействовать механизм транзакций используемой БД.
хотя, подозреваю, тут архитектуру приложения чинить надо.

← →
Александр_2012 (2014-03-21 15:14) [2]

Есть ряд правил заполнения основной таблицы, причём они могут изменяться, поэтому проверка правильности вынесена в отдельную таблицу. Поэтому просто не представляю как изменить программу. А как задействуется механизм транзакций? Можно пример или ссылку?

← →
Inovet © (2014-03-21 15:58) [3]

> [2] Александр_2012 (21.03.14 15:14)
> А как задействуется механизм транзакций?

А БД какая скажешь наконец?

← →
Александр_2012 (2014-03-24 09:25) [4]

Oracle

← →
Inovet © (2014-03-24 09:48) [5]

> [4] Александр_2012 (24.03.14 09:25)

Какой тогда ещё метод Post, если есть специальный язык - SQL называется, в нём много чего есть вообще, а уж в Оракле и ещё больше. А в частности всё это делается в рамках транзакций. Не надо пользоваться всякими TTable.

← →
clickmaker © (2014-03-24 09:51) [6]

> с помощью SQL-запросов, прописанных в отдельной таблице

это как?

← →
Александр_2012 (2014-03-24 10:40) [7]

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 10:44) [8]

> Запросы типа: select Count(*) from table1 where pole1=1
> and pole2<>5

а почему бы не делать эти проверки до внесения данных?

← →
Александр_2012 (2014-03-24 10:50) [9]

clickmaker ©
Хороший вопрос. А как? Подскажите. Разве можно выполнить SQL-запрос к таблице, пока данные в неё не занесены? В смысле запрос-то сделать можно, только он вернёт информацию о ранее внесённых данных, а не о тех, которые оператор набрал в DBEdit-ах, но ещё не подтвердил. Так ведь?

← →
Dennis I. Komarov © (2014-03-24 11:02) [10]

> Изменил OraQuery на OraTable

Вот он волшебный метод...

> Да и на SQL метод Post никто не отменял.

Чего-чего?

> которые оператор набрал в DBEdit-ах,

Вот их и надо выбросить первым делом.
Есть хранимые процедуры, пакеты... Читай про них...
А проверка лабуды, которую хотят внести в БД должна быть до внесения. Нечего всякий мусор туда тащить...

← →
Александр_2012 (2014-03-24 11:16) [11]

Dennis I. Komarov ©

> Да и на SQL метод Post никто не отменял.

Неточно выразился, хотел сказать у компонентов, работающих с SQL, т.е. OraQuery.

> которые оператор набрал в DBEdit-ах,

Вот их и надо выбросить первым делом.

Т.е. я правильно понял, что вместо DBEdit лучше использовать Edit и программно обрабатывать?

← →
clickmaker © (2014-03-24 11:20) [12]

> вместо DBEdit лучше использовать Edit и программно обрабатывать?

ну это уже от конкретной задачи зависит. Иногда лучше. Но и с DB-версиями можно валидацию делать. Н-р, TField.OnSetText, OnValidate

← →
Dennis I. Komarov © (2014-03-24 11:23) [13]

> Т.е. я правильно понял, что вместо DBEdit лучше использовать
> Edit и программно обрабатывать?

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

Данные проверил, передал в хранимку, получил результат...

← →
clickmaker © (2014-03-24 11:25) [14]

> По-хорошему (правильному) delphi-прогер не должен задумываться
> о структуре БД

Это если delphi-прогеру крупно повезло, и в конторе есть специально выделенный db-прогер. Но так далеко не всегда и не везде

← →
Александр_2012 (2014-03-24 11:28) [15]

У меня на нескольких вкладках визуализируется порядка сотни полей БД. Если использовать Edit, то при пролистывании БД придётся написать довольно большой фрагмент кода, который будет обновлять информацию во всех Edit-ах.

>TField.OnSetText, OnValidate
Спасибо, подумаю, как это можно использовать для решения задачи.

← →
Dennis I. Komarov © (2014-03-24 11:33) [16]

> Это если delphi-прогеру крупно повезло, и в конторе есть
> специально выделенный db-прогер. Но так далеко не всегда
> и не везде

А тогда и нечего на Оракуль смотреть :)

> У меня на нескольких вкладках визуализируется порядка сотни
> полей БД. Если использовать Edit, то при пролистывании БД
> придётся написать довольно большой фрагмент кода, который
> будет обновлять информацию во всех Edit-ах.

И кому нужна такая визуализация? Информация должна отображаться когда необходима, а не чтоб было...

GUI - переделать;
DB-архитектуру - скорее всего тоже...

← →
turbouser © (2014-03-24 11:36) [17]

А что мешает вставлять данные в ХП? Там же и все проверки реализовать

← →
Dennis I. Komarov © (2014-03-24 11:43) [18]

> Там же и все проверки реализовать

Не всегда можно (удобно) проверки в ХП делать, Например валидность ИНН.
Да и не БД-шное это дело :) БД должна проверять на предмет валидности своей архитектуры, а не контента

← →
turbouser © (2014-03-24 11:52) [19]

> Dennis I. Komarov © (24.03.14 11:43) [18]

Естественно не все проверки (хотя с тем же ИНН проверку на сервере сделать не трудно. Да и потом удобно в запросах скаляркой пользоваться :) )
Но логические (а судя по тому что у автора куча запросов - таки проверяется логика) вполне разумно делать в хранимке.

← →
clickmaker © (2014-03-24 11:57) [20]

> если pole1=1, то pole2 должно быть равно только 5

такие проверки лучше делать на клиенте. с выдачей соответствующего ругательства при фэйле, либо ограничением в самом контроле

← →
Inovet © (2014-03-24 13:12) [21]

> [20] clickmaker © (24.03.14 11:57)
> такие проверки лучше делать на клиенте.

Ну видишь, там сами проверки меняются от случая к случаю, видимо, по каким-то признакам. Наверное, можно хранить выражения, которые с подставленными (в параметрах) значениями выполнять на сервере. Что-то мне кажется, что база эта в стиле таблиц Ексель сделана.

← →
Inovet © (2014-03-24 13:24) [22]

Ну и да, не дело писать мусор в базу ради его проверки, даже если и транзакцию постоянно откатывать.

← →
Dennis I. Komarov © (2014-03-24 14:29) [23]

> хотя с тем же ИНН проверку на сервере сделать не трудно.

Да ну нафиг, там же разряд ключуется...

← →
Dennis I. Komarov © (2014-03-24 14:33) [24]

> Да ну нафиг, там же разряд ключуется...

+
и потом, это работа как раз GUI, юзер должен видеть что вводит...

← →
Александр_2012 (2014-03-24 15:14) [25]

Dennis I. Komarov ©
>И кому нужна такая визуализация? Информация должна отображаться когда необходима, а не чтоб было...

Именно необходимы все поля для визуализации. Скажем подробная информация об объекте.

>А тогда и нечего на Оракуль смотреть :)

Без выбора БД генерировалась не мною, изменить в основных таблицах ничего не могу, а пользоваться надо и для операторов создать удобный инструмент.

turbouser © (24.03.14 11:36) [17]

>А что мешает вставлять данные в ХП? Там же и все проверки реализовать

ХП - это что?

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

Inovet © (24.03.14 13:24) [22]

>Ну и да, не дело писать мусор в базу ради его проверки, даже если и транзакцию постоянно откатывать.

Я это понимаю, но не могу придумать другого способа реализовать множественные проверки (на сегодняшний день порядка 60), причем условия и количество проверок у нас могут меняться 1-2 раза в год. Т.е. нужна возможность легко изменять условия проверки. А писать анализатор строковых выражений - это очень сложно.

← →
clickmaker © (2014-03-24 15:24) [26]

> анализатор строковых выражений

если условия не сильно запутанные, то достаточно таблицы вида
Field FieldValue DependentField DependentFieldMin DependentFieldMax ------------------------------------------------------------------- Pole1 1 Pole2 5 5 Pole1 1 Pole3 10 15 ...

← →
turbouser © (2014-03-24 15:26) [27]

http://docs.oracle.com/cd/B28359_01/appdev.111/b28843/tdddg_procedures.htm

← →
Dennis I. Komarov © (2014-03-24 15:31) [28]

> Именно необходимы все поля для визуализации. Скажем подробная
> информация об объекте.

Вот не надо только сказки рассказывать... Так прям все поля сразу всех "объектов". Не верю!!!

> Без выбора БД генерировалась не мною, изменить в основных
> таблицах ничего не могу, а пользоваться надо и для операторов
> создать удобный инструмент.

Так про выбор СУБД вопрос не стоит, только вот программиста к ней в поставке нет

> Я это понимаю, но не могу придумать другого способа реализовать
> множественные проверки (на сегодняшний день порядка 60),
> причем условия и количество проверок у нас могут меняться
> 1-2 раза в год. Т.е. нужна возможность легко изменять условия
> проверки. А писать анализатор строковых выражений - это
> очень сложно.

А не надо придумывать... Все уже давно придумали и даже рассказали.

А если честно, то учебник по PL-SQL в зубы и грызть, грызть, грызть... начиная с самых основ: SELECT, INSERT, DELETE, JOIN, ...

> причем условия и количество проверок у нас могут меняться
> 1-2 раза в год. Т.е. нужна возможность легко изменять условия
> проверки. А писать анализатор строковых выражений - это
> очень сложно.

Я сию логику (того же ИНН и пр.) давно в dll вынес,

← →
Кщд (2014-03-24 19:19) [31]

>Александр_2012 (24.03.14 15:14) [25]
ОФОМС?

Проверки валидности данных обычно реализуются check- и referential intergity- констрейнтами и триггерами, срабатывающими на добавление/изменение записей. Эти механизмы следует изучить по документации к используемой СУБД.

> Проверки валидности данных обычно реализуются check- и referential
> intergity- констрейнтами и триггерами, срабатывающими на
> добавление/изменение записей. Эти механизмы следует изучить
> по документации к используемой СУБД.

:)))

> check- и referential intergity- констрейнтами и триггерами

это уже последний рубеж, если юзеру удалось таки прорваться сквозь всю остальную клиент-серверную валидацию.
а referential intergity - так это вообще больше не к валидности, а к целостности данных относится

clickmaker © (25.03.14 09:38) [34]

> так это вообще больше не к валидности, а к целостности данных
> относится

Разве эти понятия чем-то существенно отличаются с точки зрения прикладной области ? На мой взгляд - совсем ничем.

> [35] Игорь Шевченко © (25.03.14 10:18)

валидность, например, еmail или телефонного номера, а также условий типа "если pole1=1, то pole2 должно быть равно только 5" - это какбэ не совсем то же самое, что ссылочная целостность

> Эти механизмы следует изучить по документации к используемой
> СУБД.

Золотые слова!!! Отлить в золоте, под стекло и на стену!!!
Автору - выкинуть GUI, стукнуться хорошенько головой об стену, чтобы забыть навсегда слова вроде DBEdit и т.п. НАВСЕГДА запретить прямой доступ юзеров к таблицам, это должно быть в крови. Строить GUI надо так, как будто пользоваться им будут диверсанты, мечтающие испортить БД. Основательно познакомиться с ХП и триггерами, они помогут решить твою проблему. И ещё одно - нормальный человек может обработать мозгом за раз не более 17-20 "информационных объектов" и то это предел, а уровень комфортного восприятия заканчивается на 10 объектах, поэтому выводить на экран более 10 строк данных или более 10 характеристик какого либо объекта бессмысленно, это не воспринимается. Надо группировать различные второстепенные характеристики, убирать их с экрана и отображать только по отдельному нажатию кнопки "подробнее".

> Труп Васи Доброго © (31.03.14 10:12) [37]

Ага, ты как первый раз тут:

> Александр_2012 (24.03.14 15:14) [25]
> Dennis I. Komarov ©
> >И кому нужна такая визуализация? Информация должна отображаться
> когда необходима, а не чтоб было...
>
> Именно необходимы все поля для визуализации. Скажем подробная
> информация об объекте.

> Надо группировать различные второстепенные характеристики

PageControl рулит

по сабжу - добавить поле deleted
вставляем с признаком Удален, если корректно - убираем признак.

откат изменений в БД Найти похожие ветки