Приветствую всех.
Одна "проблемка" есть, опишу подробнее
Есть данные на SQL Server, клиент написан на VB6 с использованием ADO
Скажем следующие таблицы (во всех таблицах поля ID - IDENTITY-столбцы):
Таблица контактов
TblContactsIDContact

Есть подчиненные данные этих контактов - телефоны:
TblPhonesIDContact_IDPrefixPhone

Теперь, в клиенте базы, нужно сделать следующее, должна быть возможность при создании новой записи контакта, сразу же указывать телефоны. Это решил следующим образом:
1. Создал временную таблицу, структура почти одинаковая с TblPhones:
TblTemp_PhonesUIDPrefixPhone
В котором UID - хранит уникальный идентификатор, так вот, в клиенте, при создании новой записи в таблице контактов, генерируется уникальный идентификатор
При этом при добавлении новых записей в таблице телефонов контактов, значение UID устанавливается сгенерированный уникальный идентификатор.
При нажатии кнопки ОК, в форме добавления нового контакта выполняется следующая SQL-инструкция:

в @NewUID подставляется сгенерированный уникальный идентификатор
Таким образом, при добавлении новой записи, все добавляемые данные записываются во временную таблицу, затем, при нажатии ОК, создается контакт, получаем значение ID нового контакта, и перекидываем все записи из временной таблицы

Теперь о проблеме ;))) Необходимо реализовать "то же самое" для редактирования существующего контакта, т.е. открывается запись, в котором есть таблица телефонов контакта, можно удалять, изменять, дополнять и т.д., но пока кнопка "ОК" не будет нажата, все вводимые изменения не вступят в силу
Подумываю о варианте, изменить структуру временной таблицы телефонов на следующую:
TblTemp_PhonesIDRecord_IDUIDContact_IDPrefixPhone
Для того, чтобы при открытии формы редактирования записей, телефоны существующего контакта перекидываются в эту промежуточную таблицу, затем при нажатии кнопки ОК, обновляется реальная таблица в соответствии с изменениями в промежуточной таблице, т.е. отражаются изменения
Только здесь мне "не нравится" следующие моменты, пользователь может удалить одну запись, может изменить другую запись, т.е. нужно еще продумать реализацию обновления рабочей таблицы в соответствии с изменениями во временной таблице: если запись была удалена - удалить, новую запись - добавить, изменения - обновить в рабочей таблице и т.д.
Можно было бы еще, при открытии формы редактирования контакта, перекинуть все записи в промежуточную таблицу TblTemp_Phones, затем при нажатии ОК, удалить данные из "боевой" таблицы, и перекинуть из временной, но такой вариант тоже не подойдет, так как на ID записей будут ссылки в других таблицах

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

Пожалуйста, подсобите советами, может быть кто-то уже проходил через такое, и решил это более эффективным методом?

Спасибо за внимание и заранее благодарю за советы ;)

Можно использовать следующий метод для подтверждения редактирования существующего контакта:
1. При открытии формы редактирования, предварительно перекидываются записи из рабочей таблицы во временную
2. При добавлении новой записи значение Record_ID устанавливается в -1
3. @CID - хранит значение ID редактируемой записи в таблице контактов

И таким образом, при нажатии на кнопку "ОК" выполняется следующая инструкция:

Shocker.Proпосле второго прочтения понял, что я немножко не об этом....

А что, на TblPhones.ID действительно есть внешние ссылки? Просто непонятно, зачем, это подчиненная информация вроде как...

Реальная задача совсем другая, т.е я не совсем те таблицы как бы привел, но суть проблемы отражает
Так что считайте, что ссылки на ID в таблице TblPhones есть ;)))

Shocker.ProВ принципе, я не вижу большой проблемы в синхронизации временной таблицы с постоянной в вашем варианте.
Транзакция будет состоять из трех запросов UPDATE, DELETE и INSERT, и полностью синхронизирует временные данные с постоянными.
Свое сообщение с указанием SQL-инструкции, написал после своего первого поста, т.е. еще не видел ваши сообщения ;))
Вы о таком методе имели в виду?

Shocker.ProorunbekМожно использовать следующий метод для подтверждения редактирования существующего контакта:

и что вам в нем не нравится?

все устраивает, в принципе
просто думаю, может быть кто-то решил подобную проблему более эффективным и "элегантным" способом, как бы вынес решение проблемы на обсуждение, для нахождения "слабых мест" ;))

Shocker.Pro,

проблема использования транзакций даже не в этом, а в другом,
представьте ситуацию:
1. пользователь открывает форму редактирования контактов, открывается транзакция
2. затем открывает в другой дочерней форме совсем другие данные и редактирует их
3. после завершения редактирования переходит к форме редактирования контактов и нажимает кнопку "ОТМЕНА", соответственно выполняется откат транзакции, т.е. получается что изменения в других таблицах тоже отменяется

Shocker.Pro,

Вроде бы есть лимит количества открытых транзакций на одно подключение в ADO...
Или я ошибаюсь?

Shocker.Pro,

есть ограничение :((, в клиенте работать только через одно подключение

Shocker.Proorunbekесть ограничение :((, в клиенте работать только через одно подключение

Один экземпляр коннекшна или одно фактическое соединение с сервером? В некоторых случаях это может быть не одно и то же

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