в свете выяснившихся обстоятельств про использование FoxPro я на досуге решил поэкспериментировать:

1. создал файлик reindexDB.prg

Set Default To ('d:\_test\db1gb\')

gnDbcnumber = Adir(gaDatabase, '*.DBF')  

For nCount = 1 To gnDbcnumber

	tablename = gaDatabase(nCount,1)

	Use ''+tablename In 0 Exclusive
	Reindex
	Use
Endfor

Close All
 

2. выбрал базу размером 1 гиг, и скомпилил reindexDB.prg и запустил (перед этим принудительно работу с базой завершил аварийно)

3. время на моей рабочей машинке заняло 4:19:47 (замерял секундомером)

Результат который я получил - запустив потом базу
а) 1С-нина не поняла что базу переиндексировали, указав на индекс таблицы ПоследовательностиДокументов нарушен.
б) переиндексация средствами 1С заняла 5:20:41

Вопросы:
1) Как 1С проверяет сам факт нарушения индексных файлов?
2) Можно заставить 1С поверить что база переиндексированна (в принципе можно нажать кнопку НЕТ  , но )

Возможно еще 1С , дополнительно , проверяет индексы при открытии таблиц как в XBase :

1. Существует ли файл

ФС.СуществуетФайл(ФайлИндекс) = 1 

2. Открывается ли в режиме чтения

 БазаАдреса.ОткрытьФайл(ФайлБазы, ФайлИндекс, 1);  

3. Содержится ли необходимые индексы (выясн из МД) в  индексном файле (выясняется из файла)

Вопрос : может ли Fox внутренними методами проверить необходимость переиндексации ?

dnp писал(а) 23. Августа 2007 :: 02:47:

ИМХО это самое главное и единственное

dnp писал(а) 23. Августа 2007 :: 06:38:


если подытожить то получается на знание   1С о реиндексации могут повлиять

1. Наличие файлов *.lck в каталогеИБ(), и во всех каталогах пользователя
2. запись в таблице 1SUSERS в поле USRSCNT >0
3. наличие записей в syslog\links.tmp

То есть если проверить на ОТСУТСТВИЕ процессов 1cv7.exe в памяти и "поубивать" вышеозначенные линки можно запускать reindex средствами Fox

Осталось проверить корректно ли реиндексирует Fox по сравнению с родным 1С-овским движком - а это можно сделать выполнив UPDATE на смену родителя в каком нибудь справочнике, чем сегодня вечерком и займусь.

lustin писал(а) 23. Августа 2007 :: 12:23:

Не согласен.
Наличие 1cv7.lck для 1С ни о чем не говорит (только что проверил).
Наличие записей в syslog\links.tmp (или просто его существование) - тоже (ибо выход пользователя лишь снимает блокировку с определенного байта, находящегося за пределами файла)  (только что проверил).
Лишь ненулевой счетчик или отсутствие индексного файла - причина. Хотя при отсутствии CDX вопрос не задается.
Проверять наличие процесса 1cv7.exe не требуется (да и как узнать, относится ли он к нашей базе?), достаточно проверить отсутствие 1cv7.lck в каталоге базы, а в случае наличия - попытаться его удалить (5 лет работает батник, архивирующий базу ночью, утром могу проверить, не сообщил ли он о неудаче).

А вот переиндексация средствами Фокса - это хорошо бы. И не ради 20% экономии времени.
Мало ли чего конфигуратору в пакетном режиме икнется ночью. Потом, с утра по раньше, лети на редко посещаемую работу, ищи его, снимай... Выслушивай жалобы, что "нам же работать нужно!.. а нельзя так сделать, чтобы такого не повторялось?".

Так что предлагаю такую редакцию :

1. База свободна, если КаталогИБ()+"1cv7.lck" отсутствует или стирабелен.
2. Переиндексация нужна, если база свободна, а в USRSCNT не ноль.

Во, вспомнил ведь
В свое время, аж в 2004 г. сделал COM-объект для Опенконфа
Цитата:

+ где-то на форуме Саша Орефков сделал полезную добавку к нему

1S.StatusIB.wsc - есть в поставке скриптов Опенконф, папка СистемныеФайлы

Вкратце алгоритм такой - проверяется количество пользователей в 1susers "select usrscnt from 1susers"
если 0, то в базе нет никого и переиндексация не нужна
если не 0, то
 делается попытка монопольного открытия файла 1susers.
dbf
 если удалось открыть, значит нужна переиндексация
 если не удалось открыть, значит, кто-то сидит в базе.

Т.е. схема определения необходимости индексации очень и очень проста

А использовать этот КОМ-Объект можно в любой программе - Опенконф, системные скрипты, 1С и т.д.
Там все просто