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, либо на другую платформу. | |
| Интернет-форум Краснодарского края и Краснодара |