IB 5.6 , как сделать экпорт/импорт части таблицы через дискету?

← →
Вика (2002-01-14 13:30) [0]

Необходимо организовать пополнение удалённой таблицы, раз в неделю. Связь
с этим местом - толлько через дискету :-). Пока.

Насколько я понимаю - надо создать файл - в котором будут все необходимы "insert into ...", притащить его - куда надо, и там прогнать. И табличка пополнится.
Нет ли чего то уже сделанного для выполнения этой операции - т.е. записать SQL-выборку из таблицы в виде "insert into..."?

← →
Dr. Web (2002-01-14 14:49) [1]

Копать надо в сторону репликаций...
но, насколько я знаю в IB FireBird нет встроеной поддержки репликаций, хотя я могу и ошибаться...
У меня тоже есть такая задача... на даном этапе я еще не очень представляю как это лучше сделать (ну вот например такой вариант, когда пользер попробует закачать два раза один и тот же файл, или обновить только некоторые данные)...
НО в Лотус Ноутсе это все достигается репликациями... если че копнешь в эту сторону дашь знать, ок?

← →
Вика (2002-01-14 15:10) [2]

Dr. Web, может я чего-то не понимаю :-), но внешние и первичные-то ключи для чего?? Явно для того чтобы данные в порядочном виде сохранить. Так что два раза они никак закачаться не должны.
А репликаций в IB 5/6 нет. Это точно.
Я жду других версий решения изложенной задачи :-).

← →
Delirium (2002-01-14 15:21) [3]

Добавляешь в исходную таблицу поле-флаг, по умолчанию, допустим 0.
1) При появлении новых записей у нас появляются 0-и.
2) После корректной операции записи на дискету всех 0-ей, переводишь их в положение 1.
3) После корректного чтения/добавления информации с дискеты, привращаешь 1-цы в 2-ки и забываешь о них.

Таким образом на каждом этапе мы имеем возможность повторить действие, если оно было неудачно.

← →
Dr. Web (2002-01-14 16:19) [4]

Delirium - это уже что-то :)
Вика - все таки загвоздки имеются....
если ненадо два раза закачивать, то как тогда обновлять?
и еще много других проблем... так что.... просто первичными ключами тут не отстреляешься

← →
Delirium (2002-01-14 16:40) [5]

>Dr. Web
"если ненадо два раза закачивать, то как тогда обновлять?
и еще много других проблем... так что.... просто первичными ключами тут не отстреляешься"
Что-то, я не понял какие у тебя проблемы? Давай по конкретнее, если не устраивает схема "ключ+состояние" можно выстроить руками весь механизм отложенной репликации, с GUID-ами и очередями, а вот надо-ли так всё усложнять?

← →
Moscower (2002-01-14 23:39) [6]

Я для своего проекта применял такую тактику:
Делаю в таблице поле TRANSFER - Char(1)
Если конкретная запись еще не была перенесена в общую базу, то TRANSFER="i"
Если перенесена в общую базу, то TRANSFER="t"
Если запись была изменена (но только, если TRANSFER равнялся "t"), то TRANSFER="u"
Если запись удалена, то TRANSFER="d"

Можно добавить какие-то свои значения этого поля для работы с дискетой, и никаких проблем, все будет работать

То же самое примерно решение предложил и Delirium

← →
Вика (2002-01-15 07:21) [7]

Спасибо, ребята. Предложение Moscower - очень заманчиво :-), и одновременно просто в реализации. Но... я-то думала, что есть уже что-то готовое для таких вещей. А так-то конечно... каждый сам напишет :-). Видимо так и придётся.

← →
Moscower (2002-01-15 11:48) [8]

>> Вика

Действительно там все просто!

Если будут какие-то любые проблемы в реализации пиши на webmaster@moscower.com

← →
Bachin (2002-01-15 13:33) [9]

В свою очередь могу предложить технологию MS.
1. Заводим 2 поля Created и Changed
2. Заводим генератор (один для всех таблиц)
3. При синхронизации выбираем все, что больше последнего синхронизированого генератора и за поминаем значение генератора на данный момент.

PS в MS в роли генератора высткпает поле типа stamp
PSS само собой возникнут проблемы с удалением. советую завести поле Alive (boolean) для данных и отдельный механизм для справочников (хотя некоторые можно и по аналогии).

IB 5.6 , как сделать экпорт/импорт части таблицы через дискету? Найти похожие ветки