Есть куча копий проги, каждая со своей локальной БД, надо в случае ее копирования сменить GUID БД. Копируют юзеры - как умеют.
Копирование чаще для переноса на другой комп, но если тут GUID поменяется, то не страшно.
Ломаю голову как бы это сделать автоматом.
Единственное что придумал: задействовать потоки NTFS, они теряются при копировании на флэшку с FAT32, теряются при копировании Far`ой. Но отлично копируются проводником.

DarkMasterDima T,

Видится какое-то локальное хранилище (сайт к примеру), которое отдает пакет в виде прога + БД с измененным GUID.
Тут столько сил вложено чтобы максимально упростить перенос проги простым копированием, юзеры обучены, так что не вариант откатываться к установке с нуля.
Кроме того установка с нуля заставит юзера переносить настройки и еще кое-какую инфу, ради чего собственно копирование делается.

Немного дополню ТЗ: GUID БД нужен чтобы организовать между ними репликацию, чтобы каждый юзер видел что наработали другие. И есть центральная БД, куда все юзеры сливают наработанное, и оттуда получают наработанное другими. "Оттуда" построено так что при добавлении инфы от одной БД формируется команда всем остальным БД качать эту инфу, отсюда проблема если две БД имеют один GUID, то первая отправит инфу, а вторая не получит, или первая вперед получит команду, скачает, удалит, а вторая без инфы останется.

AkinaХрани GUID в реестре (GetSetting/SaveSetting), в качестве ключа используй полный UNC файла БД. Если в реестре пусто - генери новый случайный.
Рассматриваю как вариант. Но он наихудший. БД может быть в локалке и использоваться несколькими юзерами (они внутри БД). Добавление нового юзера, вызывает смену GUID БД, а смена GUID БД вызывает смену GUID всех юзеров БД. Все БД с их юзерами хранит центральная БД, и там будет куча "мертвых душ", оно самоочистится через полгода после смены, но засирать ими не хочется.
AkinaДругой вариант - хранить список гуидов в служебной таблице (ключ тот же). Таблицу также "еплицировать".
Это не понял, можно поподробнее.

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

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

maytonDima T, посмотри как утилита rsync работает. Может поможет.
rsync тут лишний, у меня до 1000 записей неизменяемых с гуидами, можно просто все гуиды запросить, сверить, которых нет - запросить по ним полную инфу. Это и есть полная синхронизация.
Можно вообще тупо каждый раз полный список гуидов выдавать, но как-то это совсем неоптимально.

Как определить что файл скопирован я придумал: у папки где он лежит есть дата создания.

mayton1) Регистрация базы на рабочей станции. Выдача персонального GUID.
В этом и проблема. В локалке базу могут использовать по сети. В расшаренную папку положил и можно с нескольких компов работать.
А если сеть подглючивает, админов нет, то плюют на все прелести сетевой работы и делают каждый себе копию. Бывают другие причины отказаться от сетевой работы. Вот тебе и несколько баз с одним GUID.
mayton2) Гарантия того что база актуализируется.
Верно. И как можно быстрее. Центральная БД всех заинтересованных в онлайне оповещает о наличии новой инфы.

maytonDima T, ну что я могу сказать. Совет - вынести все в веб наверное будет слишком альтруистичным?
Не, все нельзя, веб не готов к работе в режиме 24/7. Даже такие монстры как соцсети иногда падают. Да и не везде у конечных пользователей с подключением к инету все замечательно.

Dimitry SibiryakovИди от обратного: затачивай БД изначально на автономную работу с синхронизацией при первой появившейся возможности.
Я к этому и иду, эта репликация первый шаг в эту сторону, но это только часть функционала, который сейчас есть при работе в локалке. Как весь функционал сделаю - можно будет каждого юзера посадить работать автономно.

maytonЯ думаю с заказчиком просто прокашлять эту тему надо. Бизнес должен быть просто
предупрежден о том что система работает в 99% случаев в онлайне а в 1% допускается
офлайновая работа но с уведомлением пользователя. Дескыть - щас нет сети и как только
будет так сразу все заявки улетят.
Не совсем понял к какому посту это предложение. Если к скорости репликации, то тут так и есть, 99% онлайна вполне допустимо.

BarloneУ файла есть уникальный идентификатор... https://msdn.microsoft.com/en-us/library/aa363788(v=vs.85).aspx
Спасибо. Вроде то что надо. Надо затестить.

авторFile IDs are not guaranteed to be unique over time, because file systems are free to reuse them.
И тут МС на идшниках сэкономил. Как с PID. Зачем создавать потенциальную возможность сохранения ID при замене файла? Тем более что там два DWORD под ID выделено.

Затестю все варианты, отпишусь по результату.