К списку форумов К списку тем
Регистрация    Правила    Главная форума    Поиск   
Имя: Пароль:
Рекомендовать в новости

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

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



Гость
1 - 22.12.2016 - 12:55
автоудаление движений стоит на документе ?
Гость
2 - 22.12.2016 - 12:58
+ а вот без причины - "ябыпрямымзапросом" - как бы нинада
+ создать пустой (новый) МД и обновить на него
Гость
3 - 22.12.2016 - 13:31
(1)Сейчас не могу посмотреть, скорее всего - да
(2)я понимаю, а что делать ? базу надо свернуть, а с выгрузкой-загрузкой такая беда
+ создать пустой (новый) МД и обновить на него - имеется в виду, что может уйти косяк документа ?
Гость
4 - 22.12.2016 - 14:22
(0) Я так понял, что база СКЛ? Тогда методами СКЛ можно шаманить с перенумерацией таблиц, ИМХО.
Гость
5 - 22.12.2016 - 14:24
4-banzay >а если внимательно почитать, подумать и потом писать?
Гость
6 - 22.12.2016 - 14:32
(4) база файловая, написал же, но в ней никто не отменял прямых запросов к регистрам, с ними проблем нет, владею
Гость
7 - 22.12.2016 - 14:33
http://www.script-coding.com/v77tables.html
--
ACTNO Номер движения документа (включая каждое движения по регистрам и запись периодических реквизитов за исключением проводок). В случае непериодического значения заполняется нулем. Тип - Число(int).
---
http://www.1cpp.ru/forum/YaBB.pl?num=1170986603
---
http://www.forum.mista.ru/topic.php?id=251435
Гость
8 - 22.12.2016 - 15:16
1 - удаление движений автоматическое
2 - попробовал фоксом перенумеровал двойные 78 в 101 и 102, выгрузил, загрузил, все на месте. Похоже что так прокатит
Гость
9 - 22.12.2016 - 15:41
(8) я б как минимум ДД пересоздал и мд-шник накатил , какая то не здоровая фингня, релиз математики какой ?
ЗЫ есть еще нюанс с пубами и прочими проводко регистровыми - БИ идет в ногу с ОИ ? а автосоздать операцию там как на этом документе ????
Гость
10 - 22.12.2016 - 15:44
(9)27-ой
в ногу по тем счетам что ведем, но не все ведем
11 - 23.12.2016 - 08:20
А сколько записей в самой длинной таблице? У тебя может быть наступил предел по числу записей в индексном файле к этой таблице...
Гость
12 - 23.12.2016 - 08:42
(11)не считал, посмотрю. А сколько предел для CODEBASE, я уже не помню?
Сделал так
1 - снял галку "Автоматическое удаление движений". Движения удаляю программно
2 - ввел константу "Технологическое проведение" (Перечисление.Булево)
3 - в режиме технологического проведения пишу движения двух проблемных регистров в ТЗ, удаляю движения и снова пишу из таблиц значений. Перепровел таким образом, косяки ушли, последний управленческий отчет не разьехался
Сейчас попробую еще выгрузить и загрузить. Вчера попробовал от балды уникально перенумеровать ActNo, после этого не смог дождаться загрузки базы. Очень долго шел процесс
13 - 23.12.2016 - 14:22
2(12) число записей около 1 000 000 000.
Гость
14 - 23.12.2016 - 14:28
(13)до миллиарда далеко
15 - 23.12.2016 - 21:37
для дбфа в 1с - 16млн
16 - 24.12.2016 - 10:54
2(15) а что лимитирует? а то я по FoxPro помню, что в cdx под нумератор записей в таблице зарезервировано где-то в шапке места на ярд записей (https://msdn.microsoft.com/ru-ru/lib...fd3hw9(v=vs.71)).
17 - 24.12.2016 - 17:23
16-bma1 > да хз. про индексные файлы - не скажу, не в теме, а про именно DBF - лимит 16 млн, нескольо раз напрарывался, последний раз в окитябре, резал базу за 14 год (удалял движения регитсра)
18 - 24.12.2016 - 17:23
16-bma1 > если очень интересно - то я может справлюсь у спеца.. ;-)
19 - 24.12.2016 - 18:49
В заголовке DBF под количество записей отведено 4 байта (0х04 - 0х07), это получается ... это же получается 1 073 741 823 записей.
20 - 24.12.2016 - 20:55
Не, что-то не того, 4 байта ... это же 2^31 = 2 147 483 648.
2^0 + 2^1 +...+ 2^(п-1)
21 - 24.12.2016 - 21:16
Это получается по 1 байту на запись (пресловутые 2Гб), а в записи один байт служебный, метка удаления. Так что проблема будет на в количестве записей, их всегда хватит, а в структуре таблицы.
Кажись так.
22 - 24.12.2016 - 21:41
16 млн. это мало. это вообще разговор не о чем... в каком-нибудь регистре движений этот лимит при более-менее интенсивной работе лимит исчерпается меньше чем за год...
Гость
23 - 25.12.2016 - 19:26
г-н Шухер тщится показать себя "одноэсником"? Напрасный труд: Вики про DBF здесь не поможет.
В 1С ДБФ вовсе не FOXPRO. И индексы CDX не те (что, кстати, отражено в документации. Хотя читать (и даже записывать) можно. С ограничениями.
Файлы ДБФ (+CDX) действительно имеют ограничение (1ГБ). Именно на размер файла, а не на количество записей. Ограничение движка, связанное с адресацией.
Есть механизм преодоления, но я не связывался.
Не надо выкручивать из бутылки последние капли: надо либо переходить на SQL, либо на другую платформу.


К списку вопросов






Copyright ©, Все права защищены