matalataПривет!
Пишу в таблицу dbf (visual foxpro 9) минуя fox (Delphi, tdbf).

После всех добавления нужно изменить следующее значение автоинкрементного поля.

Тут http://msdn.microsoft.com/en-us/library/st4a0s68(v=vs.80).aspx нашёл, что это пишется в структуру dbf.

Вопрос: есть ли в fox команда для установки следующего значения автоинкрементного поля или есть какая-нибудь утилита для этого, чтобы не лазить HEX редактором?
Автоинкрементные поля были задуманы для того, чтобы их значение генерировалось автоматически. Эти поля вообще имеют статус Read-Only. Изменить их напрямую средствами FoxPro - нельзя. Если Вы пишите в таблицы, используя родной драйвер OLE DB от Visual FoxPro, то так и должно происходить. Поэтому ничего менять не надо.

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

Тем не менее, если Вы ищите себе приключений, то изменить реквизиты этого поля можно командой ALTER TABLE MyTable ALTER COLUMN. Но для этого опять же нужен родной драйвер OLE DB от Visual FoxPro.

matalataПопутно: в случае работы через Microsoft OLE DB provider for Visual Foxpro в часть таблиц добавление проходит нормально (включата таблицы с автоинк. полями), в чаcть - ошибка во время выполнения многошаговой операции.
Строка ADO Provider=VFPOLEDB.1;Data Source=C:\tmp\TEST_AUTOINC;Mode=ReadWrite;Password="";Collating Sequence=MACHINE

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

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

matalata1. Как точно узнать причину ошибки во время выполнения многошаговой операции при работе через OLEDB? Подозреваю, что в общем случае никак?
Почему же. Разбить многошаговую операцию на отдельные шаги. И анализировать успех или не успех каждого шага.

Кроме того, если триггера были созданы при помощи Referential Integrity (это инструмент автоматической генерации некоторых типов триггеров в FoxPro), то в случае возникновения ошибки причина ошибки будет записана в глобальный массив с именем gaErrors. Можно его проанализировать и уточнить причину.

matalata2. Что случиться страшного, если
- открыть dbf без фокса, очистить (ZAP)
- добавить N записей, автоинкрементное поле заполнять по порядку 1,2,3,..n
- из фокса сделать ALTER TABLE 1.dbf ALTER column id1 I autoinc nextvalue n step 1, reindex

Естественно, ошибка связей с другими таблицами не рассматриваются.
Тут возникает ряд вопросов

При работе через родные драйвера FoxPro Вы физически не сможете этого сделать. Автоинкрементные поля Read-Only. Их нельзя модифицировать из среды FoxPro. Вы просто не сможете заполнить это поле. Получите сообщение об ошибке (хотя его можно игнорировать).

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

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

Подробное описание структуры таблиц VFP9 (на русском) можно посмотреть здесь

Структура табличного файла (.dbc, .dbf, .frx, .lbx, .mnx, .pjx, .scx, .vcx)

Вы почему-то упорно игнорируете тот факт, что поля Integer-Autoincrement невозможно модифицировать в FoxPro. Значение таких полей формируется автоматически в момент создания новой записи. И изменить ее невозможно . Тем не менее, Вы упорно хотите формировать их значение "вручную", что прямо противоречит самой идее их использования. Может Вам стоит пересмотреть логику их использования?

Кстати, если Вы использовали родной драйвер OLE DB от FoxPro, то как же Вы смогли что-то записать в эти поля? Вы могли только подавить сообщение об ошибке о невозможности этой операции, но их значение все-равно сформировал бы сам FoxPro просто проигнорировав переданные значения. Проверьте какое значение Вы передаете и какое значение там реально записывается.

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

matalataЯ не игнорирую, просто изменяю значение не из foxpro.
Родной драйвер после ошибки ничего не пишет (в некоторые таблицы), поэтому не могу им воспользоваться.
Так не пойдет. Надо выяснить причину ошибки. Как правило, ADO умеет читать сообщение об ошибке, возвращаемое базой.

matalataСпрошу по другому: какими утилитами можно проверить на 100% целостность таблицы (dbf и fpt файлы)?
Вы опять спрашиваете не о том. Вы ищите там, где светло, а не там, где ключи потеряли. "Целостность" - это не только формальное соответствие необходимой структуре, но еще и корректное содержимое !

Ну, например, Вы в курсе, что при определенных условиях в таблице FoxPro создается специальное служебное поле с именем NullFlags? Причем это поле скрытое (невидимое) в том смысле, что из среды FoxPro его не видно. И как Вы собираетесь заполнять это поле через Вашу утилиту? Вы вообще знаете, что там хранится и зачем оно нужно? А Вы знаете как заполнять поля типа VarChar? А VarBinary? Чем отличается Character от Character(Binary)?

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

Кроме всего прочего, Вы еще и триггеры хотите отключить! Т.е. опять же исказить "правильную" структуру, но уже в рамках всей базы данных!

Другими словами, 100% проверить "целостность" может только то приложение для которого таблица и создавалась. Все остальные способы будут сомнительными. Вам ведь не приходит в голову заполнять таблицы MS SQL, скажем, через драйвер от Access. Почему же здесь Вы делаете именно это? Просто потому, что это возможно?

matalataСразу вопрос (наверное, стандартный): как после insert узнать значение автоинкрементного поля без переоткрытия?
К сожалению, общего (в смысле, универсального) решения не существует. Все способы решения будут иметь те или иные ограничения. Какой способ подойдет в Вашем случае - решайте сами

1. В FoxPro сразу после вставки записи указатель записи встает на добавленную запись. Это значит, что если сразу после вставки прочитать значение из текущей записи, то и получим код только что добавленной записи. Но как это реализовать через ADO - не знаю. Для MS SQL относительно корректно работает обновление текущей записи в RecordSet, но будет ли также корректно работать это обновление для FoxPro - не знаю.

2. Функция GetAutoIncValue() возвращает последнее созданное значение автоинкремента в текущей сессии. Но проблема в том, что она не привязана к какой-то конкретной таблице. Это значит, что если в результате вставки были добавлены записи в несколько таблиц с автоинкрементными полями, то получите значение автоинкремента из последней таблицы.

3. Функция AFields() возвращает массив, описывающий структуру таблицы. В том числе и очередное значение счетчика автоинкремента. Однако даже если не учитывать сложности передачи массива через ADO возникает неопределенность в том, кто именно последним создал новую запись. Полученное значение - это результат Вашей вставки или кто-то другой успел вставить еще одну запись после Вас?

Аналогичная проблема возникает с поиском записи с максимальным значением физического номера записи. Нет уверенности, что получим нужную запись.

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

Как следствие, сразу после добавления записи выполняем ее поиск. Но не по значению автоинкрементного поля, а по значению этого альтернативного ключа. В найденной записи считываем значение автоинкремента.

Здесь сложность в том, что далеко не все таблицы имеют альтернативные ключи.