Косяки в регистрах
 

Есть база 7.7, сильно переписанный ПУБ. Файловый вариант, 6.5 гигов вместе с индексами, самый большой файл - примерно полгига. Все работает и все бы хорошо, но вот при тестировании и при загрузке выгруженной базы ругается на "дублирование номеров движений". Написал обработку анализа всех регистров, так оно и есть, в двух регистрах "МестаХранения" и "Партии" наблюдается эта хрень. Причем (посмотрю внимательнее), только от одного вида документов, ничем не хуже, не лучше других. Складское перемещение со встроенным списанием материалов. И документов таких много, причем вроде как только с самого начала 2015 года, хотя такие документы были и гораздо раньше. Все бы ничего, программа работает, но при выгрузке - загрузке дублирующие движения загружаются неполностью, только одно из двух, второе теряется, тем самым искажая потом складские остатки. В связи с этим 2 вопроса:
1 - какова возможная причина массового появления такой ошибки
2 - как правильно исправить ? Перепроводить не предлагать. Каждый месяц сдаются управленческие отчеты, месяцы закрываются и если пойдут даже копеечные расхождения, то будет геморрой. Есть ли какие то утилиты для 7.7 по исправлению такой ситуации. Если нет, то как я понимаю, надо правильно перенумеровать поле ActNo в файле движений. Сейчас там есть дубли, для одного конкретного документа например два движение с номерами 76,78. При нумерации надо ли учитывать ActNo в других регистрах документа. То есть какие мне присвоить новые ActNo, чтобы все стало хорошо. Может кто сталкивался, чтобы мне не терять много времени. Все-таки выгрузка и загрузка идут не 5 минут. Можно ли пронумеровать косячные движения, например, начиная от ActNo = 10000. Всего там вроде поле 6 знаков. И я бы эти движения выгрузил прямым запросом, перенумеровал, кривые удалил, исправленные вставил. Ну и причину бы конечно узнать

автоудаление движений стоит на документе ?

+ а вот без причины - "ябыпрямымзапросом" - как бы нинада
+ создать пустой (новый) МД и обновить на него

(1)Сейчас не могу посмотреть, скорее всего - да
(2)я понимаю, а что делать ? базу надо свернуть, а с выгрузкой-загрузкой такая беда
+ создать пустой (новый) МД и обновить на него - имеется в виду, что может уйти косяк документа ?

(0) Я так понял, что база СКЛ? Тогда методами СКЛ можно шаманить с перенумерацией таблиц, ИМХО.

4-banzay >а если внимательно почитать, подумать и потом писать?

(4) база файловая, написал же, но в ней никто не отменял прямых запросов к регистрам, с ними проблем нет, владею

[url]http://www.script-coding.com/v77tables.html[/url]
--
ACTNO Номер движения документа (включая каждое движения по регистрам и запись периодических реквизитов за исключением проводок). В случае непериодического значения заполняется нулем. Тип - Число(int).
---
[url]http://www.1cpp.ru/forum/YaBB.pl?num=1170986603[/url]
---
[url]http://www.forum.mista.ru/topic.php?id=251435[/url]

1 - удаление движений автоматическое
2 - попробовал фоксом перенумеровал двойные 78 в 101 и 102, выгрузил, загрузил, все на месте. Похоже что так прокатит

(8) я б как минимум ДД пересоздал и мд-шник накатил , какая то не здоровая фингня, релиз математики какой ?
ЗЫ есть еще нюанс с пубами и прочими проводко регистровыми - БИ идет в ногу с ОИ ? а автосоздать операцию там как на этом документе ????

(9)27-ой
в ногу по тем счетам что ведем, но не все ведем

А сколько записей в самой [u]длинной[/u] таблице? У тебя может быть наступил предел по числу записей в индексном файле к этой таблице...

(11)не считал, посмотрю. А сколько предел для CODEBASE, я уже не помню?
Сделал так
1 - снял галку "Автоматическое удаление движений". Движения удаляю программно
2 - ввел константу "Технологическое проведение" (Перечисление.Булево)
3 - в режиме технологического проведения пишу движения двух проблемных регистров в ТЗ, удаляю движения и снова пишу из таблиц значений. Перепровел таким образом, косяки ушли, последний управленческий отчет не разьехался
Сейчас попробую еще выгрузить и загрузить. Вчера попробовал от балды уникально перенумеровать ActNo, после этого не смог дождаться загрузки базы. Очень долго шел процесс

2(12) число записей около 1 000 000 000.

(13)до миллиарда далеко

для дбфа в 1с - 16млн

2(15) а что лимитирует? а то я по FoxPro помню, что в cdx под нумератор записей в таблице зарезервировано где-то в шапке места на ярд записей ([url]https://msdn.microsoft.com/ru-ru/library/3kfd3hw9(v=vs.71[/url])).

16-bma1 > да хз. про индексные файлы - не скажу, не в теме, а про именно DBF - лимит 16 млн, нескольо раз напрарывался, последний раз в окитябре, резал базу за 14 год (удалял движения регитсра)

16-bma1 > если очень интересно - то я может справлюсь у спеца.. ;-)

В заголовке DBF под количество записей отведено 4 байта (0х04 - 0х07), это получается ... это же получается 1 073 741 823 записей.

Не, что-то не того, 4 байта ... это же 2^31 = 2 147 483 648.
2^0 + 2^1 +...+ 2^(п-1)

Это получается по 1 байту на запись (пресловутые 2Гб), а в записи один байт служебный, метка удаления. Так что проблема будет на в количестве записей, их всегда хватит, а в структуре таблицы.
Кажись так.

16 млн. это мало. это вообще разговор не о чем... в каком-нибудь регистре движений этот лимит при более-менее интенсивной работе лимит исчерпается меньше чем за год...

г-н Шухер тщится показать себя "одноэсником"? Напрасный труд: Вики про DBF здесь не поможет.
В 1С ДБФ вовсе не FOXPRO. И индексы CDX не те (что, кстати, отражено в документации. Хотя читать (и даже записывать) можно. С ограничениями.
Файлы ДБФ (+CDX) действительно имеют ограничение (1ГБ). Именно на размер файла, а не на количество записей. Ограничение движка, связанное с адресацией.
Есть механизм преодоления, но я не связывался.
Не надо выкручивать из бутылки последние капли: надо либо переходить на SQL, либо на другую платформу.