Ошибка error 120

   bvb

03.09.12 — 14:35

   Aprobator

1 — 03.09.12 — 14:36

можно попробовать свернуть базу.

   Aprobator

2 — 03.09.12 — 14:37

вот тока быстро это нефига не получится.

   vde69

3 — 03.09.12 — 14:37

   Aprobator

4 — 03.09.12 — 14:39

(3) это если на приличном серваке делать. А тут явно — обычный калькулятор.

   Fynjy

5 — 03.09.12 — 14:43

(0) А сжать файлик не пробовали?

   Ёпрст

6 — 03.09.12 — 14:47

(5) не поможет

   Ёпрст

7 — 03.09.12 — 14:47

(0) 5. нет

   Ёпрст

8 — 03.09.12 — 14:48

(0) 3. при незакрытом регистре — долго, при закрывающемся — минуты на любом размере базы.

   Ёпрст

9 — 03.09.12 — 14:49

А так.. кастрировал лишнюю аналитику в регистре и.. забыл

   bvb

10 — 03.09.12 — 14:50

   andrewks

11 — 03.09.12 — 14:52

гы-гы-гы… следующий пошёл

   Ёпрст

12 — 03.09.12 — 14:53

(10) если не делать полный пересчет регистров, то ничего.

А вот во всех отчетах за прошлые года — болт.

Перепроведение доков — аналогично.

   andrewks

13 — 03.09.12 — 14:54

4. поможет, но там есть много нюансов

   andrewks

14 — 03.09.12 — 14:55

если абстрагироваться от всего, и уверовать, что «организация через два месяца прекратит работу. «, то я бы сделал так: спец.док списания _всех_ остатков партий 31.08.12, открытие периода, 01.09.12 спец.доком — приход всех списанных 31.08.12 партий

   Ёпрст

15 — 03.09.12 — 14:56

(13) не поможет. Превышен порог в 2 гига.

   bvb

16 — 03.09.12 — 14:57

(13) я писал файл два гига

(14) файл как физически ужать чтобы сделать открытие периода ?

   andrewks

17 — 03.09.12 — 14:57

(15) ага, согласен, невнимательно прочитал. а как же они раньше-то работали?

   andrewks

18 — 03.09.12 — 15:00

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

   Ёпрст

19 — 03.09.12 — 15:00

(16) для начала, выкинуть delete всех строк, где значения всех ресурсов = 0 + сжатие.

   Kolombina

20 — 03.09.12 — 15:03

   bvb

21 — 03.09.12 — 15:03

(19)  Дело ! Может сразу все где количество равно 0 ?

   Ёпрст

22 — 03.09.12 — 15:05

(21) нет.

у тя могли «суммы» повиснуть

   Морозов Александр

23 — 03.09.12 — 15:05

когда-то была такая разработка

DBEng32 — клиент/серверное использование DBFной версии 1С:Предприятие 7.7

   bvb

24 — 03.09.12 — 15:08

(22) Я  их занулил документом корректировки себестоимости.

   andrewks

25 — 03.09.12 — 15:09

(22) если повисли только суммы — они никогда не спишутся штатным механизмом. это хуже не сдалает, максимум — разойдутся суммы в бухии и ТиС. ничего страшного при «организация через два месяца прекратит работу»

   bvb

26 — 03.09.12 — 15:09

(8) А как проверить закрывается регистр или нет на больгшом объеме ?

Ведь закрываться он должен в каждом периоде ?

   Ёпрст

27 — 03.09.12 — 15:11

(26) достаточно посмотреть на размер RA328.DBF  и сделать выводы.

Он то поди, пару метров всего ?

   bvb

28 — 03.09.12 — 15:13

(27)  475 Гб

   bvb

29 — 03.09.12 — 15:15

(27) извини описался . метров естественно

   Ёпрст

30 — 03.09.12 — 15:18

(29) вот при таком размере RA , RG должен быть метров 100 и меньше.

   Ёпрст

31 — 03.09.12 — 15:22

Измерения то в регистре какие хоть ?

   Злопчинский

32 — 03.09.12 — 15:49

(30) это при большой оборачиваемости товара. А если супермегазапасы, созданные кучей мелких — приходов всегда будет дохренища «незакрытых» партий и соотношение будет поменьше… посмотрел у сеяб сейчас RA = 205 Мб, RG = 9Мб, но у меня партии по среднему… и крупнооптовые поставки

   Ёпрст

33 — 03.09.12 — 15:51

(32) да при любом расскладе, RG<RA

   Злопчинский

34 — 03.09.12 — 15:52

(33) убедил!

   Ёпрст

35 — 03.09.12 — 15:53

если только, не односторонее движение в RA (одни приходы, к примеру)

   Злопчинский

36 — 03.09.12 — 15:54

(35) это явно учет «закормов родины»..

   andrewks

37 — 03.09.12 — 15:54

(33) не при любом

   bvb

38 — 03.09.12 — 15:59

(31) стандартные

   Злопчинский

39 — 03.09.12 — 16:02

(37) а, ну-ка, растяни баян…

   andrewks

40 — 03.09.12 — 16:05

(39) см. сабж

   Ёпрст

41 — 03.09.12 — 16:52

(38) ну, можешь всё на одну партию повесить, раз нужен только количественный учет.

   Злопчинский

42 — 03.09.12 — 16:56

(40) юморист, однако…

   Эльниньо

43 — 03.09.12 — 17:15

Детсад.

Намедни имел дело с чудом — RA 86 м, RG 1.4 гига. 10 измерений.

   Злопчинский

44 — 03.09.12 — 17:17

(43) чорная пречорная торговля за чорныйпречорный нал…

.

как-то обычно частенько забывают что касса — регистр остатокв…

и книга продаж/покупок — аналогично.. и никто не закрывает их концом месяца бо неведут книги в торговле…

   andrewks

45 — 03.09.12 — 17:19

(44) книжки — вообще прикол. представь, например, что в ТиС ведут учёт упрощенец или вменёнщик — ну вот нафига ему книжки в ТиС сводить? а типовая «всё пишет, пишет…»

   Злопчинский

46 — 03.09.12 — 17:22

(45) угу… я вообще книги, кассу, банк, вообще отрубил регистрацию.

   Эльниньо

47 — 03.09.12 — 17:31

(44) Посмотрел модули проведения.

Ни один программист не заморачивался закрытием регистра «Партии».

   Злопчинский

48 — 03.09.12 — 17:39

(47) что свидетельствует о том, что вопросы себестоимости при торговле — не главный вариант..

   Злопчинский

49 — 03.09.12 — 17:40

(47) программисты, они такие программисты… типовых не знают, ллоги ки типовых не знают, процессы в конторе — представляют слабо.. франчи/фри.. что сних возьмешь.. хоть шерсти клок — и то уже хорошо.. типа…

   Эльниньо

50 — 03.09.12 — 18:42

(49) Програмёры непричём.

Тупой работодатель — у него хороший прог тот, кто молча и быстро сделает.

   Злопчинский

51 — 03.09.12 — 19:57

(50) ну почему же тупой — работодатель получил видимо за свои деньги то что хотел на тот момент.

а вот текущий момент — он должен стоит гоооооооррррраааазззддоооооооооооооооооо дороже

   Злопчинский

52 — 03.09.12 — 19:59

У мну например аналогичная ситуевина — УРБД, 7.7, на точки мигрирует куча ненужной инфы и незакрывающийся регистр партий (поступления только в центре).. ну вот 1го числа и вывалилась аналогичная бяка — бо файло перевалило за 2 гига… по УРБД я не спец, поэтому посоветовал клиент унайти урбдшника… для крамотной свертки…

   Эльниньо

53 — 03.09.12 — 20:14

(51) Тупой работодатель получив в итоге то, что и должен был получить, пребывает в недоумении — куда «хорошие» программисты подевались.

Все кто приходит — через месяц уходят, поняв, что база в предсмертных агониях.

Работодатель принимает гениальнейшее решение — завтра быстренько и очень дешёво (опять) перейдём на УПП и всё будет как раньше.

(53) порадовал..

17:43

Столкнулся с неприятной проблемой: в одной из баз «Бухгалтерский учет 4.5», файл с бухгалтерскими итогами достиг 2 гигабайт. Естественно, ни один документ провести не получается и свернуть базу стандартной обработкой wrap.ert — тоже. При любом пересчете бухгалтерских итогов появлялось сообщение об ошибке записи в 1SBKTTL.DBF (Codebase Error #: -120. Writing to file).

Проблема усугублялась ещё и тем что в этой базе было более 300 тысяч единиц номенклатуры и несколько десятков тысяч документов за два с половиной года. В общем база данных приличного размера.

Так как у меня под рукой был настроеный сервер с MS SQL, то самым простым способом мне показалось «выгрузить данные», загрузить их в SQL, а уже там свернуть той самой стандартной wrap.ert. Более того, я уже так делал пару раз.

Но с SQL-базой не вышло. При загрузке номенклатуры, примерно на 270800-й позиции, выдавалась «ошибка загрузки данных» без объяснения подробностей. А разобраться, какой же там непечатный символ (или ещё что-нибудь) в 840-мегабайтном файле выгрузки не хочет «съесть» SQL, просто не реально.

Точно так же (по непонятным причинам), не сработал и метод с использованием kernel33.dll — файлы отказались расти больше двух гигабайт.

Пришлось решать задачу альтернативными методами.

Для начала нужно было сделать так чтобы 1С ничего не писала в файл с итогами при свёртке базы. Ведь данные об итогах добавляются при записи новых «операций вручную» с остатками. Пришлось доработать wrap.ert, заменив «операции» на непроведённые «бухгалтерские справки». Файл итогов перестал увеличиваться и все документы по вводу остатков сформировались.

Но это ещё не всё! Обработка свёртки начала удалять старые документы и тут внезапно появилась знакомая ошибка записи в 1SBKTTL.DBF. При удалении или распроведении документов в файл бухгалтерских итогов 1С всё равно что-то пишется. Оказалось для того чтобы этого не происходило, нужно «установить расчёт» (управление бухгалтерскими итогами) куда-нибудь назад, чтобы удаляемые документы были позже по дате проведения.

Помечать на удаление несколько десятков тысяч документов пришлось самописной обработкой. Ну а дальше уже всё легко: пометка на удаление всей номенклатуры, удаление помеченых объектов, снятие пометки удаления с оставшейся номенклатуры, проведение бухгалтерских справок с проводками ввода остатков, полный пересчёт итогов и упаковка таблиц базы данных.

На весь этот «путь к успеху», в моём случае, было потрачено несколько суток, но это в основном из-за большого количества номенклатуры и из-за метода «научного тыка».

Источник

не могу сформировать книгу ипшника — предприниматель загибается

перегнали все документы из бухгалтерии в предпринимателя, поставили предпринимателя со скуэлем на отдельном нефиговом серваке, работает сутки, обрабатывает полгода (объем данных весьма внушителен, в бухгалтерии весь год занимает 4 гига дэбээфов) и загибается:

Error #: -120
writing to file
d:docume

120 — ошибка записи в файл.

запускали на разных серваках, со скуэлем и в дбф, резалт одинаков.

Что делать?
Может есть какой-то еще способ сформировать книгу?

не знаю, не замеряли.
есть какая-то критическая масса? 🙂 прикидывали че он может туда писать — под 4 гига должно получиться.

сейчас запущу еще раз и взвешу, но результаты взвешивания будут только завтра.

а на 8-й платформе книга ип-шника как-нибудь делается?

я правильно понял что по достижении объема 2 Гб dbf не просто работает очень медленно, а перестает работать вообще как либо (типа границы в 4 Гб адресного пространства на 32-битных машинах)?

в таком случае есть ли у меня какие-то еще варианты кроме как взять разбег метров 100 и разбиться головой об бетонный забор вокруг нашей фирмы? цена вопроса сейчас пока неинтересна, есть ли он вообще в принципе?

(4) Да, действительно, размер файла растет до 2 Гб потом ошибка.

т.е. можно идти и искать хорошее крепкое место в заборе?

Источник

Извините, но данная страница отсутствует. Возможно, вы ошиблись, набирая адрес, или ссылка устарела.

Последние новости

Федеральная антимонопольная служба опубликовала для металлургических компаний данные для расчета акциза на жидкую сталь за декабрь 2022 года.

Эксперты Роструд разъяснили, вправе ли работодатель индексировать не всю заработную плату, а только часть оклада равную МРОТ.

ФНС разъяснила, применяют ли правило о прекращении исчисления транспортного налога в отношении автомобиля должника, на которое судебным приставом наложен арест.

В 2023 году продолжит действовать мораторий на проведение внеплановых проверок в отношении ККТ.

Мероприятия

• Где купить СОФТ
• Вакансии фирм-партнеров «1С»

• Центры Сертифицированного Обучения
• Интернет курсы обучения «1С»
• Самоучители
• Учебный центр № 1
• Учебный центр № 3

• Сертификация по «1С:Профессионал»
• Организация обучения под заказ
• Книги по 1С:Предприятию

• WWW.1С.ru
• 1С:Предприятие 8
• 1С Отраслевые решения
• Образовательные программы
• 1С:Линк
• 1С:Консалтинг
• 1С:Дистрибьюция
• 1С для торговли
• 1С-Онлайн
• 1С Интерес
• 1С:Образование
• 1С:Торговая площадка
• 1C:Игры
• 1Софт
• ИТС.1C.ru

При использовании материалов активная прямая гиперссылка на перепечатанный материал обязательна.

Редакция БУХ.1С не несет ответственности за мнения и информацию, опубликованную в комментариях к материалам.

Редакция уважает мнение авторов, но не всегда разделяет его.

Мы используем файлы cookie, чтобы анализировать трафик, подбирать для вас подходящий контент и рекламу, а также дать вам возможность делиться информацией в социальных сетях. Если вы продолжите использовать сайт, мы будем считать, что вас это устраивает.

Источник

Adblock
detector

Довелось столкнуться с такой вот ситуацией: более 10 лет используется конфигурация «Торговля и склад». Очень даже успешно используется, была немного доработана, работает быстро, делает что нужно. В общем, идиллия. Но ничто не длится вечно…

В один «прекрасный» день, а точнее в ночь на первое число как обычно в монопольном режиме попытался открыть период, и вот тебе раз:

Очень даже не вовремя. Первое число выпало на среду, нужно работать, а никак. База довольно большая, поэтому тестирование и исправление не помогло ни в каких вариантах. За первую ночь ничего не решил. Единственным выходом было установить рабочую дату на последний день прошлого месяца и работать таким образом. Здесь необходимо отметить, что этот вариант следует использовать только в качестве крайней меры, так как все сопутствующие документы также придётся заводить этой датой. В первую очередь это касается документов поступления. Чтобы не возникло путаницы, в будущем мы договорились в комментарии документов указывать реальную дату и ручками после решения проблемы вернуть всё на круги своя.

Итак, полумеры были приняты, взялся за дело. Так что же такое за «Error #: -120»? Выяснить не составило особого труда. Эта ошибка возникает, когда размер файла dbf превышает 2Gb. Не буду утверждать на 100%, но это вроде как не только проблема базы данных 1С версии 7.7, но и всех DBF в целом. Отсортировал все файлы в базе данных по размеру и действительно: удивительно, поразительно. Он единственный такой большой, следующий по величине в три раза меньше.

Первым делом посмотрел файл 1Cv7.DD, который содержит описание всех таблиц информационной базы. Оказалось, что это регистр «Книга продаж»

#===============================================================================
#==TABLE no 157    : Регистр КнигаПродаж
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=RG4343  |Регистр КнигаПродаж           |A          |RG4343     |1         
#——Fields——-
# Name      |Descr               |Type|Length|Precision
F=PERIOD    |Period Registr      |D   |8     |0        
F=SP4336    |(P)КредДокумент     |C   |13    |0        
F=SP4337    |(P)СтавкаНДС        |C   |9     |0        
F=SP4365    |(P)ВидДолга         |C   |9     |0        
F=SP4338    |(P)СуммаНДС         |N   |16    |2        
F=SP4339    |(P)СуммаРуб         |N   |16    |2        
F=SP4340    |(P)СуммаНП          |N   |16    |2        
#—-Indexes——
# Name     |Descr         |Unique|Indexed fields                                              |DBName     
I=PROP     |PERIOD+PROP   |0     |PERIOD,SP4336,SP4337,SP4365                                 |PROP       
#

Первое, что пришло в голову, это ещё раз попробовать сделать тестирование и исправление со следующей комбинацией галок:

   При просмотре файла выяснилось следующее: в колонке «Period Registr» стоял 2005 год и записей было очень много, потом 2006, 2007 и так далее. Так как эти записи относились к более ранним периодам, а документы в журнале начинались с 2011 года, соответственно было сделано предположение, что кто-то сворачивал базу, может и неоднократно, но вероятно, немножко кривыми ручками. Предполагалось, что после пересчёта итогов лишние записи уберутся и останется только изящно запустить тестирование и исправление ещё раз, но уже только с одной галкой «Упаковка таблиц информационной базы».

   На это была убита ночь со среды на четверг, но к огромному огорчению, к открытию магазина процесс не завершился, пришлось всё останавливать, доставать базу из архива и работать опять на 31 числе прошлого месяца. К сожалению, я не смог придумать никакого способа хотя бы примерно оценить время выполнения данной операции, а в данном случае эта оценка весьма бы пригодилась для принятия решения.

   Ситуация начинала уже раздражать. Всегда неприятно ощущать бессилие перед программой. Попросив пользователей ещё денёк поработать на 31 числе на ночь с четверга на пятницу была предпринята попытка свернуть информационную базу за 2 года в надежде сократить размер злополучного файла.

   Как только завершился рабочий день, разумеется сделав архив, запустил свёртку базы на 1.01.2013 года, так как документы там были с января 2011 года. Утром с огорчением увидел, что процесс ещё во всю идёт, а уже нужно начинать работать. Опять попросил уже изрядно нервных пользователей потерпеть, и стал думать, ЧТО ЖЕ ДЕЛАТЬ???!!!!

   Слава Богу, суббота и воскресенье выходной и соответственно и плечо раззудится, и рука размахнётся. В пятницу после завершения рабочего дня, быстренько сделал архив и снова запустил свёртку на мощном сервере. Но для надёжности взял домой базу, чтобы не класть все яйца в одну корзину.

   Пока сервер мощно гонял электроны по многочисленным ядрам своих процессоров и усердно жужжал дисками, свёртывая базу, было решено решить проблему кардинально. Разумеется, было страшно, не натворю ли я дел? Поэтому было решено вспомнить об устройстве этого регистра.

   Пришлось порыться в документации. Основное назначение регистра «Книга продаж» — оперативное ведение учета НДС по каждому покупателю. Залез в конфигурацию, просмотрел, как он работает:

Нажал на волшебную кнопочку «Описание» и узнал всё, чо нужно:

Регистр «Книга продаж» предназначен для ведения учета НДС, выставленного
покупателям в расходных документах. Движение приход регистра производится при
проведении документов реализации ТМЦ и услуг покупателям и движение расход — при
включении сумм в книгу продаж (документами «Формирование книги продаж» и
«Запись книги продаж»). По этому регистру производится построение отчета «Книга
продаж».

СТРУКТУРА РЕГИСТРА «КНИГА ПРОДАЖ»

ИЗМЕРЕНИЯ

КредДокумент
Здесь проставляется значение документа, которым были реализованы ТМЦ или услуги
покупателю.

СтавкаНДС
Ставка НДС.

ВидДолга
Вид долга, может принимать значения из перечисления «Виды долга». Практически
означает бухгалтерский счет, на котором ведется учет выставленного покупателю НДС.

РЕСУРСЫ

СуммаРуб
В этом ресурсе ведется учет суммы продаж всего, включая НДС и НП, в валюте
бухгалтерского учета.

СуммаНДС
В этом ресурсе ведется учет суммы НДС продаж, в валюте бухгалтерского учета.

СуммаНП
В этом ресурсе ведется учет суммы НП продаж, в валюте бухгалтерского учета.

РЕКВИЗИТЫ

КодОперации
Код хозяйственной операции движения.

ДокументОплаты    
Документ оплаты задолженности. Документ оплаты, по которому произошло
включение в книгу продаж. Проставляется при формировании движения по
включению сумм в книгу продаж.

СтавкаНП
Ставка НП продажи. Проставляется при проведении документов реализации. 

Возможно, кому-то это регистр крайне необходим, но похоже, это не наш случай, и я подумал, раз десять лет этот регистр горько не был никому нужен, то и дальше не понадобиться. А что если удалить из него все записи?

   А дальше как в песне, «как легко на плоской карте стрелку начертить, а потом идти придётся через горы и овраги….». Нужен был инструмент для выполнения данной операции. Так как я не любитель копаться в dbf, взял то, что подсказал Яндекс. И был это DBF Commander. Обалденная программа, на 20 дней выдаётся бесплатно. Разумеется, можно было взять любую другую, но зачем тратить время, если она позволяет добиться результата. Повторюсь, ни в коем случае не рекламирую эту программу, подойдёт любая, позволяющая удалять записи из DBF и паковать его, даже Visual FoxPro.

   Открыл при помощи DBF Commander файл RG4343.DBF, там оказалось почти 25000000 записей!!! Открывался файл минуты три. В меню «Правка» оказался очень удобный пункт «Удалить все записи», им я и воспользовался. Commander жевал файл почти час, уже готов был испугаться, но наконец-то все записи покраснели. Осталось только выбрать следующий пункт «Паковать таблицу».

   После этой процедуры файл из многотонного бегемота больше двух гигов превратился в пушинку 257 байт. Не забыв удалить индексный файл RG4343.CDX, запустил программу в монопольном режиме. Индекс моментально перестроился и вышло приглашение открыть новый период.

   С замиранием сердца я ждал результат. И вот он сладкий миг победы!!! Период открыт! Причём очень быстро. Попробовал перепровести несколько реализаций, всё хорошо. Они вызывают записи в RG4343.DBF, но с нулями в колонках.

   На всякий случай обратился ещё раз к 1Cv7.DD:

#===============================================================================
#==TABLE no 158    : Регистр (Дв.) КнигаПродаж
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=RA4343  |Регистр (Дв.) КнигаПродаж     |A          |RA4343     |1         
#——Fields——-
# Name      |Descr               |Type|Length|Precision
F=IDDOC     |ID Document’s       |C   |9     |0        
F=LINENO    |LineNo              |N   |4     |0        
F=ACTNO     |Action No           |N   |6     |0        
F=DEBKRED   |Flag Debet/Kredit   |N   |1     |0        
F=SP4336    |(P)КредДокумент     |C   |13    |0        
F=SP4337    |(P)СтавкаНДС        |C   |9     |0        
F=SP4365    |(P)ВидДолга         |C   |9     |0        
F=SP4338    |(P)СуммаНДС         |N   |16    |2        
F=SP4339    |(P)СуммаРуб         |N   |16    |2        
F=SP4340    |(P)СуммаНП          |N   |16    |2        
F=SP4341    |(P)КодОперации      |C   |9     |0        
F=SP4342    |(P)ДокументОплаты   |C   |13    |0        
F=SP5345    |(P)СтавкаНП         |C   |9     |0        
#—-Indexes——
# Name     |Descr         |Unique|Indexed fields                                              |DBName     
I=IDLINE   |of IDDOC+LineN|0     |IDDOC,LINENO,ACTNO                                          |IDLINE     
#

   Это движения того же самого регистра. Он содержал около 350000 записей. На всякий случай зачистил и его. В результате получил значительное ускорение работы всей базы.

   Возможно, у проблемы было и другое решение. Если интересно, давайте обсудим.

   Зачем я всё так подробно описал? А потому, что ситуации у всех разные и не нужно, возможно, стрелять из пушки по воробьям. Может, кому-то поможет тестирование и исправление, а может просто прочтение этого материала натолкнёт на спасительную мысль.

   Надеюсь, моя статья кому-то поможет.

Category:

• IT
• Cancel

Столкнулся с неприятной проблемой: в одной из баз «Бухгалтерский учет 4.5», файл с бухгалтерскими итогами достиг 2 гигабайт. Естественно, ни один документ провести не получается и свернуть базу стандартной обработкой wrap.ert — тоже. При любом пересчете бухгалтерских итогов появлялось сообщение об ошибке записи в 1SBKTTL.DBF (Codebase Error #: -120. Writing to file).

Проблема усугублялась ещё и тем что в этой базе было более 300 тысяч единиц номенклатуры и несколько десятков тысяч документов за два с половиной года. В общем база данных приличного размера.

Так как у меня под рукой был настроеный сервер с MS SQL, то самым простым способом мне показалось «выгрузить данные», загрузить их в SQL, а уже там свернуть той самой стандартной wrap.ert. Более того, я уже так делал пару раз.

Но с SQL-базой не вышло. При загрузке номенклатуры, примерно на 270800-й позиции, выдавалась «ошибка загрузки данных» без объяснения подробностей. А разобраться, какой же там непечатный символ (или ещё что-нибудь) в 840-мегабайтном файле выгрузки не хочет «съесть» SQL, просто не реально.

Точно так же (по непонятным причинам), не сработал и метод с использованием kernel33.dll — файлы отказались расти больше двух гигабайт.

Пришлось решать задачу альтернативными методами.

Для начала нужно было сделать так чтобы 1С ничего не писала в файл с итогами при свёртке базы. Ведь данные об итогах добавляются при записи новых «операций вручную» с остатками. Пришлось доработать wrap.ert, заменив «операции» на непроведённые «бухгалтерские справки». Файл итогов перестал увеличиваться и все документы по вводу остатков сформировались.

Но это ещё не всё! Обработка свёртки начала удалять старые документы и тут внезапно появилась знакомая ошибка записи в 1SBKTTL.DBF. При удалении или распроведении документов в файл бухгалтерских итогов 1С всё равно что-то пишется. Оказалось для того чтобы этого не происходило, нужно «установить расчёт» (управление бухгалтерскими итогами) куда-нибудь назад, чтобы удаляемые документы были позже по дате проведения.

Помечать на удаление несколько десятков тысяч документов пришлось самописной обработкой. Ну а дальше уже всё легко: пометка на удаление всей номенклатуры, удаление помеченых объектов, снятие пометки удаления с оставшейся номенклатуры,  проведение бухгалтерских справок с проводками ввода остатков, полный пересчёт итогов и упаковка таблиц базы данных.

На весь этот «путь к успеху», в моём случае, было потрачено несколько суток, но это в основном из-за большого количества номенклатуры и из-за метода «научного тыка».

Определение «You have attempted to login in too many times»

«You have attempted to login in too many times» часто называется ошибкой во время выполнения (ошибка). Разработчики программного обеспечения, такие как SoftwareDeveloper, обычно работают через несколько этапов отладки, чтобы предотвратить и исправить ошибки, обнаруженные в конечном продукте до выпуска программного обеспечения для общественности. К сожалению, многие ошибки могут быть пропущены, что приводит к проблемам, таким как те, с ошибкой 120.

После установки программного обеспечения может появиться сообщение об ошибке «You have attempted to login in too many times. Try again later. The general sense is that — you are too often connected to the server and it is temporarily closed access to your IP address, in order to prevent possible attacks, and just to avoid the incre». Когда это происходит, конечные пользователи могут сообщить Mirabilis о наличии ошибок «You have attempted to login in too many times». Mirabilis может устранить обнаруженные проблемы, а затем загрузить измененный файл исходного кода, позволяя пользователям обновлять свою версию. Чтобы исправить такие ошибки 120 ошибки, устанавливаемое обновление программного обеспечения будет выпущено от поставщика программного обеспечения.

Почему возникает ошибка времени выполнения 120?

Ошибки выполнения при запуске ICQ — это когда вы, скорее всего, столкнетесь с «You have attempted to login in too many times». Мы рассмотрим основные причины ошибки 120 ошибок:

Ошибка 120 Crash — программа обнаружила ошибку 120 из-за указанной задачи и завершила работу программы. Как правило, это результат того, что ICQ не понимает входные данные или не знает, что выводить в ответ.

Утечка памяти «You have attempted to login in too many times» — ошибка 120 утечка памяти приводит к тому, что ICQ использует все больше памяти, что делает ваш компьютер запуск медленнее и замедляет вывод системы. Возможные искры включают сбой освобождения, который произошел в программе, отличной от C ++, когда поврежденный код сборки неправильно выполняет бесконечный цикл.

Ошибка 120 Logic Error — Вы можете столкнуться с логической ошибкой, когда программа дает неправильные результаты, даже если пользователь указывает правильное значение. Это происходит, когда исходный код Mirabilis вызывает недостаток в обработке информации.

Такие проблемы You have attempted to login in too many times обычно вызваны повреждением файла, связанного с ICQ, или, в некоторых случаях, его случайным или намеренным удалением. Как правило, решить проблему можно заменой файла Mirabilis. Если ошибка You have attempted to login in too many times возникла в результате его удаления по причине заражения вредоносным ПО, мы рекомендуем запустить сканирование реестра, чтобы очистить все недействительные ссылки на пути к файлам, созданные вредоносной программой.

Распространенные сообщения об ошибках в You have attempted to login in too many times

Усложнения ICQ с You have attempted to login in too many times состоят из:

• «Ошибка в приложении: You have attempted to login in too many times»
• «Недопустимый файл You have attempted to login in too many times. «
• «Возникла ошибка в приложении You have attempted to login in too many times. Приложение будет закрыто. Приносим извинения за неудобства.»
• «Файл You have attempted to login in too many times не найден.»
• «You have attempted to login in too many times не может быть найден. «
• «Ошибка запуска программы: You have attempted to login in too many times.»
• «Не удается запустить You have attempted to login in too many times. «
• «You have attempted to login in too many times выйти. «
• «Ошибка в пути к программному обеспечению: You have attempted to login in too many times. «

Обычно ошибки You have attempted to login in too many times с ICQ возникают во время запуска или завершения работы, в то время как программы, связанные с You have attempted to login in too many times, выполняются, или редко во время последовательности обновления ОС. При появлении ошибки You have attempted to login in too many times запишите вхождения для устранения неполадок ICQ и чтобы HelpMirabilis найти причину.

Источник ошибок You have attempted to login in too many times

Заражение вредоносными программами, недопустимые записи реестра ICQ или отсутствующие или поврежденные файлы You have attempted to login in too many times могут создать эти ошибки You have attempted to login in too many times.

В частности, проблемы You have attempted to login in too many times возникают через:

• Недопустимый You have attempted to login in too many times или поврежденный раздел реестра.
• Загрязненный вирусом и поврежденный You have attempted to login in too many times.
• You have attempted to login in too many times злонамеренно или ошибочно удален другим программным обеспечением (кроме ICQ).
• Другая программа, конфликтующая с You have attempted to login in too many times или другой общей ссылкой ICQ.
• Поврежденная установка или загрузка ICQ (You have attempted to login in too many times).

Продукт Solvusoft

Загрузка
WinThruster 2022 — Проверьте свой компьютер на наличие ошибок.

Совместима с Windows 2000, XP, Vista, 7, 8, 10 и 11

Установить необязательные продукты — WinThruster (Solvusoft) | Лицензия | Политика защиты личных сведений | Условия | Удаление