Каждый день уходя с работы включаем индексацию...
Раньше она длилась максимум 20 мин. Сейчас в два раза больше. Есть ли какой-то способ, чтобы сократить это время? Заранее очень благодарен всем ответам.

сноси все индексы перед этим.

есть.
Быстрые диски и много оперативки.
+оптимизация отборов и сортировок.

надеюсь, не по сети делаете?

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

Исправить косяки в базе. Есть незакрытые регистры очевидно.

20 мин это уже ненормально

(0) поставить SQL. вообще не надо будет делать индексацию

(0) (экстрасенсирую) незакрытые регистры наверняка есть

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

(0) Сделайте дефрагментацию диска на котором лежит база.

(10) ты забыл посоветовать протереть монитор и почистить клаву

Поставить SQL нет возможности - связан по рукам и ногам....

(11) И мышку! Мышку обязательно.

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

(12) переведи всех на терминалку. чтобы вообще только с терминалки заходили. тогда индексы у файловой не летят.

(9) скажи название самого большого файла в базе.

все и так работают на терминалке)))

(12) Судя по всему и мозгам... Смотри что за остатки накапливаются. Какие-то регистры в каких-то разрезах не выходят в ноль. Поэтому каждый месяц итогов все больше и больше и все приходится пересчитывать. Разберись где эта шняга, выведи в ноль что левое висит, и сделай чтобы в дальнейшем ошибка не повторялась.

(16) тогда ж.па :)

(14) более глупого совета я еще не слышал. Это про терминал если чо...

Обрежь им базу. Ускоришь индексацию в разы

(20) начинать нужно с аудита базы. если в базе копиться хрень, то обрезка базы тоже поможет ненадолго, обычно на год, максимум два.

(20) грамотно!!! ржу в голос!!!

(19) а я более глупого ответа чем твой тут не слышал :)

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

(22)
"на 2000 у меня были проблемы с быстродействием...
- и как решили?"
-- перевел на 2005 сиквел.
- проблем не было?
-- были!
- и как решили?
-- перевл всех на 2000 !!!"
© Из беседы с кандидатом, 1986 г.р.

(24) смотря какая у него база.

+ вот нафика было нормального программиста в штат приглашать, если у тетки истерика?
ЭЫ это ж доктора надо тогда

filh, самый большой 1sconst.dbf.

(25) гггггггггг!!!!!!!!! ))))))))) А ведь сплошь и рядом такие ОЧумельцы

(29) у тебя франчази фирма убежала. бросай попкорн иди директорь.

(28) схожие по размеру есть? кинь сюда топ по размеру. И какая конфа у тебя?

(28) не верю! ©

(32) А я верю. Настрогали очень много периодики. Скорее всего использовали периодический реквизит там, где на самом деле нужен регистр. :)

(33)+ Какие-нить остатки хранят в периодическом реквизите справочника номенклатуры или контрагентов. И такое бывает...

2. 1sconst.cdx 212 мб
3. 1sjourn.cdx 78 мб
4. Dh1611.dbf 93 мб
5. Dt1611.dbf 119 мб

явно бестолковая конфигурация судя по (35)...

(35) Адын пропустил )

Ra328.dbf 300 мб
Ra4480.dbf 106 мб

Дядя Васька, не пропустил первый я уже выкладываел выше)

(35) с такими объёмами не может так долго индексировать

(39) ну во-первых, первый вышеупомянутый у тебя за нумером 2 числится. во-вторых, он не лидер по размеру. Так что садись - КОЛ!

я и не пытался упорядочить по убыванию...

зайди в папку БД, выполни там: dir >flist.txt
появившийся файл flist.txt выложи на zalil.ru

4. Dh1611.dbf 93 мб
5. Dt1611.dbf 119 мб
Хороший документик!

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

А к Ra328.dbf и Ra4480.dbf с теми же номерами сколько весят?

(43) Лучше dir /OS >flist.txt

(47) не усложняй ;-)

(46) "А к Ra328.dbf и Ra4480.dbf с теми же номерами сколько весят?" = "А к Ra328.dbf и Ra4480.dbf RG*.dbf с теми же номерами сколько весят?"

(48) Ну сразу по размеру встанут просто, легче посмотреть будет.

http://zalil.ru/32525059

регистр R*328 (скорее всего, остатки) у тебя не закрывается. + подозрительно большая периодика. в этих направлениях и рой

(0) лови гранату:
Диспетчер устройств - Диски - Твой диск - Свойства - Политика - Включить повышенную производительность.
Скорость переиндексации увеличится.

Вот только если свет пропадет, или уборщица розетку зацепит - велика вероятность потерять данные

В идеале (если нет денег на обновление железа + грамотную настройку ОСи) - просто свернуть базу. В первую очередь периодику. И (52)+++ регистры проверить на незакрытость.

R*405 - то же самое. это остатки, а R*328, наоборот, партии

(52,54) Они оба закрыты, если что.

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

FN, стоит ИБП - так, что думаю все нормально будет...

Косяк вестимо где - в отборах на текстовых полях.

И видать, еще количество и общих реквизитов с галкой отбор - ну просто дофига.

(58) вот щас как раз об них и думал. больше вариантов нет (если только, конечно, рэйд не сыпется. но тогда в целом бы всё тормозило)

Рейда нет - один жесткий диск!

У меня была перенаправлялка CDX на другой диск.
http://x-romix.narod.ru/ CDX_MOVER.rar (40K) - позволяет переместить файлы CDX на другой диск
Еще можно посмотреть что там с антивирусами - параметрами индексирования папки - не убит ли диск и т.д.

Еще бывает длительное построение индекса и большие файлы CDX, если слишком много измерений.
Несколько косяков DBF-баз при достижении файлами определенного размера описывает Hogik на Инфостарте.