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