Господа лисоводы, как граммотно провести программную модификацию таблиц БД на серваке согласно эталонной.

Не знаю, грамотно это или нет, мы так делаем
Проект и exe содержать 3 свободных вмороженных таблицы, содержащих список баз данных, таблиц в них, полей в таблицах, их типах, длине, дефолтах, индексах-именах, выражения итд
Перед посылкой клиентам очередной версии программы запускаем программу, которая считывает всю информацию с наших таблиц. При запуске заказчиком новой екзе, полученной от нас, программа видит, что версия сменилаь, пытается захватить эксклузив и идет по вмороженным таблицам и сравнивает их теми, что есть реально. Если видит, что какой то таблицы нет-делает ее. Если добавлено поле ( изменен его тип или длина) делает эти изменения. Так же с индексами.
Если база каким то образом поломалась у клиента, этот же блок отремонтирует ее. Иногда таблицы приходится ронять из базы и присоединять назад, иногда полностью стирать cdx
Поскольку в 6 версии validate database recover нельзя делать из екзе, вморожен еще и голый контейнер базы, на случай, если сломался он.

это получается, что нужно постоянно отслеживать изменения структур таблиц и самой БД и записывать их в эти 3 таблицы?

Как понять "отслеживать"... Изменения в структуре сам же программер и делает. Написал себе небольшую програмулину, которая делает "слепок" с моих таблиц и заодно генерит программу переиндексации. У пользователя в проге по некоему флагу запускается блок обновления структуры БД... ну все, как Владимир Журавлев написал... А при подготовке нового дистрибутива для пользователя я по своему усмотрению включаю в дистрибутив этот самый файл-флаг, при наличии которого и запускается обновление, затем файл удаляется. И все.

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

> У пользователя в проге по некоему флагу запускается блок обновления структуры БД... ну все, как Владимир Журавлев написал...[color=Blue][/color]

А где это он писал?

А когда запись изменений будет срабатывать?
И можно ли где подробнее прочитать про события БД (VFP8SP1)?

Я такие вещи стараюсь держать весьма строго. Вариантов отслеживания можно придумать много, вот, например, один, который я предпочитаю:
В каталоге с самой БД лежит свободная табличка, где написан номер реализации программы, которой разрешено подключаться к данной БД. Если не соответствует или отказ в попытке подключения или запрос на преобразование. Эсли этой таблички нет, то вопрос на как минимум тестирование структуры является обязательным, и при успешном окончании все-равно эта табличка будет создана.

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

При открытой базе данных modi data
на сером фоне базы правая кнопка мыши или в меню датабейс
идете в меню и ищете плашку свойства самая нижняя
Правая кнопка мыши -список событий
Щелкаете нужное вам -выскакиват затравка такого события
Скажем , если нужно запретить кому то открыть таблицу и известным именем
возвращаете в коде события .f.
PROCEDURE dbc_BeforeOpenTable(cTableName)
*Just before a table or view is opened. Return .F. to prevent table or view being opened.
IF ATC("dvds",cTableName)#0 AND UPPER(ALLTRIM(INPUTBOX(DVDLOGIN_LOC,DVDLOGINCAP_LOC)))#"ADMIN"
* Since this is a sample, we will ignore password, however, you can enforce it by returning .F.
* RETURN .F.
RETURN .T.
ENDIF
ENDPROC
Если нужно отслеживать изменения таблиц -код сохранения структуры можно положить в aftermodifytable,
Таблицы, в которые сохраняете структуру базы сами в этой базе быть не должны
Так можно сделать полный аудит, кто когда что добавлял, менял итд

Если уже есть собственный словарь БД (описание структуры БД), то логично не ручками лазить в БД и изменять структуру, после чего не забывать обновлять словарь, а сделать собственный интерфейс ведения словаря с функцией обновления структуры БД по нему.

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

Можно завести в БД табличку с версиями БД и в программе должны быть процедуры обновления для каждой версии. Если скажем, текущая версия БД 2.1.35, а обновление делается до 2.1.41, то последовательно выполняются процедуры апдейта для всех существовавших промежуточных версий. Кстати, бывает полезно различать версии программы и базы данных, номер версии БД должен быть зашит в самой БД, а номер софта - в нем. И программа должна знать, с какими версиями БД она может работать.

Это все может показаться надуманной ерундой , но если проект более-менее большой и софт используется во многих организациях (у меня были сотни) - другого решения, более приемлемого для сопровождения, я не знаю.

Hi zilot!

Я всегда ВСЕ изменения в структуру таблиц делал не через диалоги MODI STRU и
им подобные, а путём написания команд ALTER TABLE, INDEX ON и т.д.
Соответственно эти команды я вносил в prg-ку, на основе которой потом и
получался "модуль обновления". Кроме того я в dbc храню в Comment номер
версии, потому все изменения я делаю "пачками" (т.е. в модуле обновления
прописаны ВСЕ изменения, окружённые условными блоками) - и могу от любой
"старой" версии перейти к последней - по очереди выполнятся все необходимые
блоки - лишние выполнены не будут.
Этот-же номер проверяется и в программах работающих с базой. Теоретически
можно сравнивать на >= (исходим из того, что поля НЕ удаляются, и более
новая версия БД обратно совместима со старой - т.е. "расширяет" её) но я
обычно сравниваю на точное равенство...

zilot
А где это он писал?

Я имел ввиду сам механизм обновления, описанный Владимиром, а не конкретную фразу "по некоему флагу".
У меня сделано по пути создания словаря БД+ сам контейнер БД+програмка переиндексации. Все таблицы, индексы, вьюшки - все корректно изменяется у пользователя.

2zilot

Слепок с таблиц делается в момент создания новой версии (т.е. *.exe).
Должна быть спец. программуля такая.

А что если сделать так:
просканить эталонный каталог с БД,записав структуры таблиц в dbf.
Создать такие же dbf для рабочих таблиц.
Модифицировать рабочие таблицы, сравнивая структурые dbf(Alter-SQL).
Скопировать в рабочий каталог эталонные индексные файлы и контейнер БД.
Выполняем переиндексацию модифицированных рабочих таблиц.

2zilot
2Igor Korolyov

А зачем так сложно ? Последовательно отрабатывать переходы от версии к версии.
Для корректной работы достаточно, чтобы номер версии БД и софта совпадали.
Ну и изменяй структуры существующих таблиц и индексы, создавай новые пустые
от любой (младшей) версии до текущей. Новые справочники ? Это другой вопрос.
Или я не понял

In USA 90% of VFP data use Stonefield. At my former job I wrote DataDictionary application myself... Here we're using Stonefield.

Hi IGOR_SMIRNOVSKY!

Не вижу ничего сложного. Зато в разных точках установки могут находится
разные версии (ну пропустил кто-то очередной апдейт ) и любая из них
может быть "доведена" до нужной кондиции.

Hi All!

Подход Stonefield насколько я помню основан на собственных расширениях
метаданных (т.е. именно на "словарях данных" как тут многие писали). Из
явных минусов - цена и необходимость интегрироваться с этим продуктом (на
что не все могут пойти)... Хотя продукт несомненно мощный, автор -
достойнейший человек и крупный специалист (увы сейчас AFAIK он несколько
отошел от фокса).

>IGOR_SMIRNOVSKY
>Ну и изменяй структуры существующих таблиц и индексы, создавай новые пустые

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