VFP9 helpAPPEND PROCEDURES is not available in a distributed executable file
Т.е. append procedure даже из родного EXE не сработает. Не говоря уже об OLE DB.

Если бы Вы описали саму задачу, а не выбранный Вами способ решения, возможно, Вам посоветовали бы другие способы решения. Модификация структуры данных "на лету", да еще и из стороннего приложения, крайне порочная практика. По возможности, такие решения следует избегать.

gudusЗадача: есть база дынных fox pro, которая установлена на как минимум 50-ти компьютерах. В неё необходимо добавить одну таблицу, пару процедур, а также на уже существующие таблицы повесить триггеры на update, insert и delete. Вот и вся задача. т.к. я не очень разбираюсь в visual fox pro, да и разбираться особо времени нет, решил все сделать на C# через oledb.
Что получилось сделать на данных момент:
1. через EXECSCRIPT() добавить процедуру
2. создать таблицы(обычный create table)
3. Триггеры, с ними тяжко(... на рабочей машине где установлен vfp через VisualFoxpro.FoxApplicationClass из C# получилось всё,
но вот при тестах на другой машине, винда и программа(база для теста), ни чего не вышло. Ругается на не возможность использовать COM объект, и пока на 3-й день копаний результат хреновый..(

Если есть какие-нибудь предложения, буду очень рад, любая идея(нормальная=)), обязательно опробую и отпишусь!
1. На компьютере, где установлен рабочий FoxPro для разработки делаете все необходимые модификации непосредственно в среде разработки FoxPro
2. На клиентские компьютеры копируете измененные файлы DBC, DCT, DCX (это контейнер базы данных с "телом" хранимых процедур и настройках триггеров) и одну новую таблицу - файлы с расширением DBF, CDX, FPT (DBF- таблица, CDX - индексы, FPT - мемо-поля, может не быть). В данном случае как-то изменять все прочие файлы DBF - не надо, поскольку сделанные изменения их никак не затрагивают

Все. Никаких модификаций "на лету" делать не надо. Все сводится к банальной замене файлов, поскольку информация о триггерах хранится вовсе не в файле DBF, а в контейнере базы данных (DBC).

Да, на всякий случай, разумеется, перед модификацией и копированием сделайте резервную копию всех файлов.

Dima TВладимирМ2. На клиентские компьютеры копируете измененные файлы DBC, DCT, DCX...
Не всегда это работает. После такой процедуры БД может перестать открываться только по причине испорченного контейнера БД.
"Контейнер БД" - это и есть DBC, DCT, DCX. "Испорченный контейнер БД" - это повреждение одного из этих файлов или их рассинхронизация. Т.е. ошибка копирования. Как следствие, при возникновении такой ошибки надо просто повторить копирование.

Если же у разных клиентов разные версии контейнера БД, ну, это ты сам себе злобный буратино Придется делать несколько модификаций контейнера БД для каждой версии.

Лично я считаю как раз наоборот. Как правило , в подавляющем большинстве случаев, подмена контейнера БД вполне себе штатный механизм обновления. В некоторых исключительных случаях, так делать нельзя. Но это именно исключения (!) обусловленные либо "кривой" структурой базы данных (Alter Table в рабочем приложении - именно что "кривое" решение), либо особо сложным обновлением.

В данном конкретном случае не вижу никаких проблем с подменой DBC. Если, конечно, само приложение было реализовано "нормально". Без "выкрутасов"...

Народ, Вы учитывайте, что, во-первых, автор вопроса не в курсе разных "заморочек" и тонкостей в структурах. А, во-вторых, в случае, если подмена DBC - не проходит, то еще далеко не факт, что прямая модификация DBC как DBF тоже подойдет. Например, что делать с версионностью? Прежде чем пугать новичка разными ужасами, сначала надо попробовать простое решение...

Dima TЧто кривого в том что по мере развития рабочего приложения требуется изменение структуры БД?
Зависит от того, когда именно происходит изменение структуры. Если в процессе "накатывания" обновления (новая версия), то это нормально. А если в процессе работы приложения, то это в корне не верно.

По Вашему описанию я понял так, что у Вас непосредственно пользователь прямо в процессе работы приложения добавляет поля. Поскольку в противном случае непонятно, откуда может взяться разный порядок следования полей. Ведь источник обновления версий один. Т.е. код "накатывания" обновлений не может быть разным. Значит, при "штатном" обновлении версии порядок полей у всех таблиц будет одинаковым.

Dima TВот как раз из-за версионности приходится так делать.
В этом нет никакой необходимости. Всегда можно выполнить подмену DBC. Надо просто понимать, что именно (какая информация) хранится в файле DBF, а какая в DBC. Стандартный порядок накатывания обновления выглядит так:

1. Создать Backup
2. Alter Table для создания/изменения нужных полей (только имя, тип, размер, то, что хранится в DBF) и индексов
3. Если необходимо, Update+Insert+Delete для заполнения/изменения новых/старых структур
4. Замена DBC

Через Alter Table меняется только то, что не хранится в DBC, а потом просто подменяется старый DBC на новый. Все. Нет необходимости создавать дополнительные проблемы.

Dima TКак выше писал в примерах от MS так сделано. Посмотри что gendbc генерит.
Так нельзя же "тупо" копировать то, что дает MS без понимания смысла. Надо понимать что это пример, преследующий вполне определенную цель. Создать ОДИН файл для генерации ПУСТОЙ базы данных. В случае модификации (обновления) структуры такой подход является ущербным. Особенно, в случае необходимости поддержания версионности.

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

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