powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / нужна блокировка!!!
5 сообщений из 30, страница 2 из 2
нужна блокировка!!!
    #36860143
songv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
не верю своему счастью! всё получилось !
Залезли в дизайнер БД

Во вкладке TABLE для убрали процедуру, которую в UPDATE TRIGGER прописала сама БД, когда устанавливали свойства для головной таблицы (правила для изменения записи в родительской таблице - cascade). И в которой автоматически происходило снятие блокировки, установленное нами программно.
И всё заработало как надо!
Да, гуид код (который у нас используется как уникальный по гражданам ) тут был ни при чем, но когда после его формирование из головной таблицы происходила запись во все подчинённые таблицы этого кода (по cascade), тут блокировка и слетала. Решили в триггер не лезть. Прописали все replace в подчинённые базы вручную. И все установленные блокировки/разблокировки заработали, как надо.
Большое спасибо за участие всем!
Видимо, целостность данных, которая определена таким образом возможностями БД именно для этой нашей задачи не подходит. Остаётся надеяться, что убрав её, где-нибудь чего-нибудь не порушится. Бум тестировать.
...
Рейтинг: 0 / 0
нужна блокировка!!!
    #36860203
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
songvне верю своему счастью! всё получилось !
Залезли в дизайнер БД

Во вкладке TABLE для убрали процедуру, которую в UPDATE TRIGGER прописала сама БД, когда устанавливали свойства для головной таблицы (правила для изменения записи в родительской таблице - cascade). И в которой автоматически происходило снятие блокировки, установленное нами программно.
И всё заработало как надо!
Следует только помнить, что при следующей автоматической генерации Referetial Integrity эта функция опять пропишется в свойства таблицы.

Update-Cascad означает тот факт, что при изменении кода Primary Key в родительской таблице автоматически должен измениться Foreign Key в подчиненной таблице.

Разобрать код хранимых процедур, формирующихся при использовании Referential Integrity не так уж и сложно. Хотя, как правило, особого смысла в триггере на обновление нет. Первичные ключи обычно не изменяются на протяжении всего времени существования записи. Как следствие, не возникает причин для обновления внешних ключей в подчиненных таблицах.
...
Рейтинг: 0 / 0
нужна блокировка!!!
    #36860306
songv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ВладимирМ, мы хитрее поступили. cascade прописывается для append blank.
Мы заменили команду на insert - cascade при этом не существует (это в той статье написано, на которую вы ссылались), а модификацию таблицы написали проверенным ручным методом.
Т.Е. нет append blank - не отрабатывает триггер из процедуры для cascade - соотвтетсвенно не сбрасыаается наша блокировка.
И БД менять не нужно!
...
Рейтинг: 0 / 0
нужна блокировка!!!
    #36861010
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
songvВладимирМ, мы хитрее поступили. cascade прописывается для append blank.
Мы заменили команду на insert - cascade при этом не существует (это в той статье написано, на которую вы ссылались), а модификацию таблицы написали проверенным ручным методом.
Т.Е. нет append blank - не отрабатывает триггер из процедуры для cascade - соотвтетсвенно не сбрасыаается наша блокировка.
И БД менять не нужно!
Что-то Вы крупно не понимаете.

Если Вы создаете новую запись следующим образом:

Код: plaintext
1.
2.
3.
4.
APPEND BLANK
* Здесь сохранение "пустой записи"
REPLACE MyField Wiht MyValue
* Здесь сохранение внесенных изменений

То у Вас при первом сохранении после APPEND BLANK сработает триггер на вставку (Insert-триггер). А после второго сохранения (после Replace) сработает триггер на обновление (Update-триггер)

Команда Insert-SQL - это команда на вставку. Поэтому триггер на обновление, естесственно, не сработает.

Конечно, использование Insert-SQL удобнее. Но здесь не понятно, а зачем Вы вообще после APPEND BLANK делали сохранение пустой записи? Почему не дождались заполнения всех необходимых полей и только потом сделали сохранение? Или Вы не знаете как это реализовать?
...
Рейтинг: 0 / 0
нужна блокировка!!!
    #36861976
songv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ВладимирМ, именно insert sql.
Программа досталась нам в наследство. Поэтому технология сохранения была уже прописана со своим порядком. Данные по гражданам находятся не в одной таблице, чтоб так легко можно было в одну строчку всё заполнить, а в шести со сложным основным ключом и кучей подчинённых.
...
Рейтинг: 0 / 0
5 сообщений из 30, страница 2 из 2
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / нужна блокировка!!!
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]