InvisibleЕсть две таблицы в разных базах, которые содержат одну и ту же информацию.
При изменении одной таблицы, должны изменяться данные в другой через таблицу базы "обновления", в которой выделены только те записи, которые отсутствуют или ОТЛИЧАЮТСЯ ХОТЯ БЫ ПО ОДНОМУ ПОЛЮ .

Дык вот как бы создать табличку(данные подлежащие обновлению) пограмотнее, да пошустрее???

если mdb/базы на sql находятся в локальной сети то крайне редко есть необходимость делать 2(две)таблицу лучше дополнительные поля- флажки

если базы разнесены то есть стандартные приемы репликации - целая отрасль науки о построении СУБД - ищи по конфе

приёмы отличаются скоростью/надежностью канала/мерами обеспечения безопасности

в идеале ставится отдельный "монитор" который все рулит

Invisible[quot Владимир Саныч]База выходит за пределы локальной сетки.

Есть копия таблицы, подлежащей обновлению и новосозданная таблица.
я понял так что существуют 2 копии таблицы Master и Slave
территориально разнесенные

копия Slave неким образом транспортируется в ЛВС к Master
извлекается таблица рассогласования которая транспортируется в ЛВС Slave
где применяется к Slave для согласования с Master ?
(причем на вреия транспортировки изменение Slave запрещено)

правильно ли я сформулировал твою схему ?

есть правильное решение:
поле FLAG тип Long которое бизнес-логикой Slave ставится в -1 при любом Insert/Update и соответственно сбрасывается в 0 монитором репликации

тогда на Master стороне Where Flag = -1(True)

если сервера синхронизованы или поднята служба точного времени то ещё не помешает поле дата(время)

теперь по сути задачи
если наша таблица справочник то она всегда распространяется от Master к Slave иначе ключи сломаются
если наша таблица содержательная то получается встречная репликация её рулить очень сложно

InvisibleMaster является справочником (Slave- его копия на другом терминале). Но ключей ни в одной, ни в другой таблице нет, т. к. записи в Master-е не определены каким-то одним диапазоном.

терминале - обьясни
ключей ни в одной, ни в другой таблице нет - более чем плохо

- вероятно целиком справочник нельзя пересылать из-за размера а хочется уменьшить траффик путем пересылки изменённых строк - это понятно



КАК ДЕЛАТЬ UPDATE записи в таблице не имеющей ключа ?


решение создать в Master ключ - счетчик в Slave - одноименное поле Long
+ создать в Master поле FLAG Long

при любых Insert в Master FLag поднимается =1
при любых Update в Master FLag поднимается =2
2 временные таблички : на изменение и модификацию
запрос на выборку Where Flag=1 ---> temp1
запрос на выборку Where Flag=1 ---> temp2
после построения временных таблицы Flag=0

на стороне Slave
temp1 --> Insert поле счетчика из temp1
temp2 -->Update поле счетчика идет в Where или INNER JOIN

редукция

как можно удалить запись из таблице не имея ключа/что сидит в Where ?
код пжалста !

автор
помимо изменения существующих записей, в Master-е могут появляться новые и уходить старые записи.


если нет ключа и могут появляться новые и уходить старые записи
то не существует алгоритма сравнения
НЕВОЗМОЖНО ВЫБРАТЬ СТРОКИ для дальнейшего сравнения их содержимого

ИТОГО:Ты что-то недоговариваешь - колись
а то Саныч со штурмовой винтовкой придет и хандец!

Invisible
Вот, вот - у меня 9 полей, каждое из которых значимое - какое из них ключевое???

могут-ли повторяться идентичные наборы этих 9 полей ?
если не могут то 9 полей образуют ключ - позволяя однозначно идентифицировать запись в таблице.
если могут повторяться - то работать с ней(таблицей) через sql ,как с элементом реляционной базы крайне сложно - придётся открывать RecordSetы
и заменять INNER JOIN на свою собственную логику.

Bely
Ничего лучше не придумал, кроме как сравнение по "значимым" полям.
Пользователю показываются различающиеся записи и он уже сам решает что принимать, а что нет.

Если нужен полностью автоматические режим - то можно сделать что-то похожее на Access replication. проверять дату модификации... задать приоритет данных источников и т.д.
про Where и составной ключ понимаю.
Пытаюсь добиться от автора ответа про устройства данных - выходит туго.
От твоей задачи коренное отличие - у тебя встречная репликация с "ручным" принятием решений
У автора однонаправленное(от Master) распространение справочника - необходимость инкрементного(кумулятивного) обращения с ней не понятно!

Bely авторВот, вот - у меня 9 полей, каждое из которых значимое - какое из них ключевое???
Все поля. Это у тебя просто составной ключ, фактически.
Только нет остальных свойств ключа - уникальности комбинации, как минимум.

нет остальных свойств ключа - уникальности комбинации
Это не так ,если нельзя однозначно определить запись(уникальность) - не ПЕРВИЧНЫЙ ключ
- нельзя делать UPDATE число записей будет 0 или >1
- нельзя сравнивать строки 2-х таблиц ,если в каждой выбирается >1