Приветствую, рухнула файловая база, при получении обновления от центральной базы, выпадает ошибка см. в теме, ругается на RG9495.CDX, поглядел что это какой то регистр, вопрос, решится ли моя беда, если я удалю этот файл и сделаю реиндексацию, или придется делать пересчет итогов в тестировании и исправлении, что очень бы не хотелось

Размер дбф файла какой? И сколько записей в нем?

(1) 68 966 КБ DBF, 34 769 КБ CDX

+ (2) Судя по размеру, до лимита еще далеко

(1) Сделал копию, попробывал удалить CDX и сделать переиндексацию, заругался на dbf, бросил эту затею, накатил копию, пусть пока работают пока решение не найду)

RG можно смело удалить и пересчитать итоги (не перепроводить!)

(5) Боюсь что будет очень долго пересчитывать, а у магазина простой, машинки слабенькие

(4) и что за ошибка?
И вьювером глянь что в дбф

(7) Не совсем умелец им пользоваться, но я так полагаю если зеленая галочка в строке, значит все ок?

1. сделать свежую копию (с испорченым файлом) [заодно закинуть е в бэкап]
2. из копии удалить все RA кроме соответствующего проблемному, и все RG
3. пересчитать итоги в копии (это будет быстро, фактически - один регистр)
4. перекинуть в рабочую RG и его индекс (будут некорректны текущие остатки по этому регистру). запретить на всякий случай работать раньше текущей даты.
5. как будет время даунтайма - сдвинуть ТА на конец прошлого периода остатков и вернуть  назад на последний док для пересчета последнего периода в RG (без перепроведения)
(пересчитаются итоги за последний период)
6. перепровести доки с "момента сбоя" до последнего документа

Для начала тупо удалить все цдх и перестроить индексы заново

(10) так он удалил индекс. 70 ошибка - это "разрушен файл данных", если правильно помню.

(10) Я удалил этот RG9495.CDX, не все конечно, а один, зашел монопольно началось реиндексирование, и вылетела ошибка -70 но уже на RG9495.DBF
Щас вьювером прошелся,везде зеленые галочки

(12) см (11)

(12) с написания (9) прошло 2 часа. Сделал?

(0)(11)
-70
Reading File.
An error occurred while reading a file. This could be
caused by calling d4go with a nonexistent record
number.

int d4go( DATA4 *data, long recordNumber )
Function d4go reads the specified record into the record buffer and recordNumber
becomes the current record number. Before reading the new record, d4go writes the
current record buffer to disk if the record changed flag is set.
If memory optimizations are being used, use d4skip instead of d4go when
sequentially reading data file records. When memory optimizations are used,
CodeBase detects the sequential skipping and automatically optimizes the operations
when d4skip is used.
Parameters:
recordNumber
This long value specifies the physical record number to read into the record buffer. To
succeed, recordNumber must be
> 0 and <= d4recCount .

(8)
Не факт.
(0)
Чаще всего такая ошибка возникает из-за порчи заголовка DBF.
Или длина файла не соответствует значению «Число записей в файле».
=================================================================

Структура базы данных (типа .DBF)

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

╔══════════════════════════════════════════════════════════╗
║         Запись заголовка в файле с данными               ║
╟───────┬──────────────────────────────────────────────────╢
║ Байты │              Описание                            ║
╠═══════╪══════════════════════════════════════════════════╣
║ 00    │Типы файлов с данными:                            ║
║       │ FoxBASE+/dBASE III +, без memo - 0х03            ║
║       │ FoxBASE+/dBASE III +, с memo   - 0х83            ║
║       │ FoxPro/dBASE IV,      без memo - 0х03            ║
║       │ FoxPro                с memo   - 0хF5            ║
║       │ dBASE IV              с memo   - 0x8B            ║
╟───────┼──────────────────────────────────────────────────╢
║ 01-03 │Последнее изменение (ГГММДД)                      ║
╟───────┼──────────────────────────────────────────────────╢
║ 04-07 │Число записей в файле                             ║
╟───────┼──────────────────────────────────────────────────╢
║ 08-09 │Положение первой записи с данными                 ║
╟───────┼──────────────────────────────────────────────────╢
║ 10-11 │Длина одной записи с данными (включая признак     ║
║       │удаления)                                         ║
╟───────┼──────────────────────────────────────────────────╢
║ 12-27 │Зарезервированы                                   ║
╟───────┼──────────────────────────────────────────────────╢
║ 28    │1-есть структ.составной инд.файл (типа .CDX),0-нет║
╟───────┼──────────────────────────────────────────────────╢
║ 29-31 │Зарезервированы                                   ║
╟───────┼──────────────────────────────────────────────────╢
║ 32-n  │Подзаписи полей**                                 ║
╟───────┼──────────────────────────────────────────────────╢
║  n+1  │Признак завершения записи заголовка (0х01)        ║
╚═══════╧══════════════════════════════════════════════════╝

╔══════════════════════════════════════════════════════════╗
║                    Подзаписи полей                       ║
╟───────┬──────────────────────────────────────────────────╢
║ Байты │                Описание                          ║
╠═══════╪══════════════════════════════════════════════════╣
║ 00-10 │Название поля (максимально - 10 символов, если    ║
║       │меньше 10, то дополняется пустым символом (0х00)) ║
╟───────┼──────────────────────────────────────────────────╢
║ 11    │Тип данных:                                       ║
║       │ C - символьное;                                  ║
║       │ N - числовое;                                    ║
║       │ L - логическое;                                  ║
║       │ M - типа memo;                                   ║
║       │ D - дата;                                        ║
║       │ F - с плавающей точкой;                          ║
║       │ P - шаблон.                                      ║
╟───────┼──────────────────────────────────────────────────╢
║ 12-15 │Расположение поля внутри записи                   ║
╟───────┼──────────────────────────────────────────────────╢
║ 16    │Длина поля (в байтах)                             ║
╟───────┼──────────────────────────────────────────────────╢
║ 18-32 │Зарезервированы                                   ║
╚═══════╧══════════════════════════════════════════════════╝

     Примечания по структуре файла с данными:

       *  Данные  в  файле  с  данными начинаются с позиции,
     указываемой в записи  заголовка в байтах  08-09. Записи
     с  данными  начинаются  с  байта,  содержащего  признак
     удаления. Если в этот байт занесен пробел в коде  ASCII
     (0х20), то запись не удалялась; если же в первом  байте
     -  звездочка  (0х2A),  то  запись удалена. За признаком
     удаления  следуют  данные  из  полей,  названия которых
     находятся в подзаписях полей.

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

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

(18) маловероятно. в RG как минимум период, т.е. 8 байт+измерение+ресурс (пусть даже вместе запись 10 байт). Записей в ДБф - 2^30. Т.е. такой файл уже вылазит за 10Г

(18) При чтении дбфки вижу 1387121 записей, скажите а допустимо ли, что запись есть но абсолютно пустая
Например:
PERIOD   SP9491   SP9492   SP9493   SP9494
*Есть*   *Есть*   *Есть*   *Есть*   *Есть*

А в самом низу таблицы н-ное кол-во записей
PERIOD   SP9491   SP9492   SP9493   SP9494
*Пусто*   *Пусто*   *Пусто*   *Пусто*   *Пусто*
Но при этом галка зеленая

(20) Знленая галка - это необычно. галка обычно черная. https://upload.wikimedia.org/wikipedia/commons/thumb/b/b1/Coloeus_monedula_-Ham_Common%2C_London_Borough_of_Richmond_upon_Thames%2C_England-8.jpg/275px-Coloeus_monedula_-Ham_Common%2C_London_Borough_of_Richmond_upon_Thames%2C_England-8.jpg

(21) Галченок)))

(22) тебе дали методику решения сутки назад. А ты в дерьме ковыряешься, пытаешься исправить вторичные (которые все равно расчитываются) данные.

(22) Скорее всего именно не соответствует реальное количество записей количеству записей в заголовке дбф файла. я когда-то на турбопаскале написал утилитку для исправления клипперовских баз. В инете видел такие утилитки

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

(23) Единственное, сделать это в ночную)

Кстати, а почему мне простой пересчет итогов не поможет?

(25) простой 2 раза по5 минут в рабочее время для _оперативного_ ввода в работу. и 20 минут в даунтайм
Впрочем ССЗБ

(27) потому, что отношение радиусов стремится к нулю

(29) Я тебя услышал братулец, спасибо за то что вверху)

(20)
«скажите а допустимо ли»(с)
В CodeBase - допустимо. А в способах/алгоритмах работы 1С с CodeBase - не допустимо.
В 1С+CodeBase такое может образоваться при сбое в момент фиксации транзакции.

(29) Твой способ проблему не решил, проблема была именно в пустых ссылках, после их удаления, все завелось