Вход | Регистрация
    1  2   
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: Порезать базу. 80% сделано, осталось 20% и застрял.

v7: Порезать базу. 80% сделано, осталось 20% и застрял.
Я
   evgpinsk_
 
21.05.20 - 22:30
Изначально dbf подобрались к двум GB. Удалось ужать самый большой файл до 1300Мб. Но иногда проблемы вылазят, поэтому всё-таки нужно резать базу.
Подрезку написал, остатки по регистрам и счетам формирую, документы до этой даты удаляются. Вроде всё ок.

Но к сожалению гладко только в теории. Уже неделю пытаюсь пройти последние 20% пути и ни как:

1) Если пытаюсь штатно удалять документы например за 15лет (с 2003 года база, удаление и за двое суток не происходит, а больше по времени ждать нет возможности).
2) Если удалять например по 2010й год штатными средствами 1с, то процесс завершается /12 часов на это нужно примерно/, но после этого ломаются промежуточные итоги.
После одной попытки подрезки они могут быть пустыми на любую дату, либо могут быть увеличенными на 2. Т.е. почемуто ломаются итоги.
3) Если удаляю документы через :
Соединение = "Provider=VFPOLEDB.1;Data Source=" + КаталогИБ() + ";Exclusive=Yes;Mode=ReadWrite;Collating Sequence=MACHINE";
метод конечно очень быстрый, но насколько я понимаю, после этого способа по определению промежуточные итоги будут содержать не верные данные?

Удаляю CDX и запускаю ТиС - над одной копией 4ро суток ждал завершения и не дождался. Над другой копией могу дождаться, но итоги не исправляются.

Уже устал бороться /учитывая, что кучу времени каждая операция занимает/ - отсюда этот пост )
http://prntscr.com/sla2bh

Неужели единственный выход - распроводить все документы после даты подрезки и затем заново их проводить?
 
 
   Gbpltw
 
1 - 21.05.20 - 23:20
прояви фантазию, ептить. перенеси в новую базу документы ввода остатков и документы этого года
   Надо работать
 
2 - 21.05.20 - 23:50
(0) думал, 1300 Гб
А тут мегабайты)
   GreyK
 
3 - 21.05.20 - 23:56
(2) Так это 7ка.
   GreyK
 
4 - 21.05.20 - 23:58
(0) Так перенеси в SQL, это из вредных советов :)
   lodger
 
5 - 22.05.20 - 00:08
(1) таким путём можно и в нормальной клиент-серверной 1с8.3 оказаться...
   GreyK
 
6 - 22.05.20 - 00:14
(5) А зачем?
   lodger
 
7 - 22.05.20 - 00:19
(6) СЛАУ решать. менеджер криптографии. телеграмм-бот через систему взаимодействия.
   lodger
 
8 - 22.05.20 - 00:20
(7) "из коробки" без тонны костылей и левых компонент.
   Шурик71
 
9 - 22.05.20 - 00:59
(0) простые и баянистые советы:

1. Если данных слишком много - режь мелкими периодами, 3-5 лет

2. Почему у тебя на скриншоте документы остатков датированы 1.01.17? Чтобы остатки были на начало 01.01.17 - документы ввода должны быть 31.12.16.

3. Заметно удалить быстрее получается, если
- если период удаления небольшой - то удалять "в обратном порядке", с последнего к первому документу
- если период удаления большой, то перед удалением откатить ТА (и рассчитанные БИ) до первого документа, а потом пересчитать итоги.
   Шурик71
 
10 - 22.05.20 - 01:00
(9+) "а потом пересчитать итоги." = "вернуть ТА и БИ без перепроведения, только пересчет итогов"
   Злопчинский
 
11 - 22.05.20 - 02:32
сформировать доки остатков. заполненые, но непроведенные
откатить ТА и БИ на перед первым обрезаемым доком.
распровести. удалить в доках ТЧ.
потом пометить на удаление (возможно придется помечать и удалять порциями)
докатить ТА и БИ до первого документа остатков.
провести доки ввода остатков.
докатить ТА и БИ без перепроведения до сейчас.
удалить штатно.
.
я совсем недавно резал базу с 2007г. по 2018. обрезал достаточно быстро.
зависит и от обьемов базы конечно. может у тебя там в каждой секунде по 10 доков впихнуто.
.
сколько документо всего до обрезки?
   Klesk
 
12 - 22.05.20 - 02:49
   GreyK
 
13 - 22.05.20 - 03:27
(11) У, как всё сложно, проще надо. Берешь базу, делаешь новую, переносишь в неё "правильные остатки" и справочные данные, а потом переносишь текущие документы. Делал так много раз, и с типовыми, и даже с очень не типовыми.
   GreyK
 
14 - 22.05.20 - 03:29
+(13) Единственное условие - это ставишь запрет на изменение данных до даты свертки.
   Гобсек
 
15 - 22.05.20 - 03:57
(13) Вот я пару лет назад попробовал обрезать БП 3 и пришлось вернуть все взад, т.к. свертка прошла некорректно.
Посоветуешь сделать новую базу и перенести "правильные остатки"? Если это делать, то какой процедурой? Или все-таки свертка?
   Aleksey
 
16 - 22.05.20 - 04:06
(15) сравнил 7ку с 8кой. Бп 3.0 это такая хрень что нормально порезать её целое искусство. Тут надо знать связи и внутреннюю структуру. Тут не получиться херак херак и в продакшен
   Bigbro
 
17 - 22.05.20 - 04:10
учитывая что база небольшая - действительно конвертнули бы в SQL и жали дальше спокойно еще лет 15.
SQL express вроде как бесплатный, для ваших объемов должно хватить с головой.
   Гобсек
 
18 - 22.05.20 - 04:58
(16) Спасибо за информацию. Будем эксплуатировать долго и упорно тот вариант, который есть. Проблема вполне может разрешиться сама собой. Например, переход ЗУП 2.5 -> ЗУП 3.1 попутно решил проблему обрезки базы. Учет в ЗУП 3.1 начинается с чистого листа. Процедуру переноса предоставила фирма 1С уже готовую. Правда, после этой процедуры пришлось еще обработками кое-что поправлять. Но это немного.
   MWWRuza
 
19 - 22.05.20 - 08:16
Если эта база на оперативном учете, например ТиС, без бухгалтерских счетов и журнала расчетов, то на ИС была очень неплохая методика "обрезки" базы. Отдельная маленькая конфигурация, которая "режет" регистры на документ свертки(добавляется предварительно в рабочую базу) прямыми запросами. Все это происходит очень быстро, значительно быстрее, чем всеми другими методами. Результат - пользователи обычно даже не замечают, что с базой что-то делали, все остатки и обороты за "оставленный" период - на месте. Единственный недостаток - это то, что обрезку можно выполнить только на ПЕРВОЕ число периода, а не на последнее, как было-бы правильнее. Но, это обходится так - если хотим свернуть(обрезать) базу на начало года - режем на 01.12.предыдущего года. Тогда остатки на 01.01.текущего года будут правильные.
Можно отрезать базу этим методом, "с запасом", оставив несколько месяцев до желаемой даты свертки, регистры "похудеют" до вменяемых размеров, а потом, уже сворачивайте своими методами, как хотите, если вместе со сверткой вы планировали еще чего-то сделать.
   MWWRuza
 
20 - 22.05.20 - 08:20
   evgpinsk_
 
21 - 22.05.20 - 08:52
(11) Примерно так и делал кроме 
"откатить ТА и БИ на перед первым обрезаемым доком."
Сейчас буду пробовать
   evgpinsk_
 
22 - 22.05.20 - 08:55
(13) Каким образом переносить?
Ведь в таком случае всё-равно придётся перепроводить оставшиеся нужные документы в новой базе. А их перепроведение очень не желательно, т.к. скорее всего гдето по какимто документам проводки станут другими. и потом кучу времени придётся тратить на их поиск
   evgpinsk_
 
23 - 22.05.20 - 08:58
Как увидеть что 1с чтото делаем в момент ТиС а не подвисла? /кроме диспетчера есть способ? например какойто файл растёт?/
http://prntscr.com/sliig5
вот уже помоему вторые сутки. До этого все птчики ставил - 4го суток и не было результата
   serpentt
 
24 - 22.05.20 - 09:04
   evgpinsk_
 
25 - 22.05.20 - 09:30
Не понимаю.Провёл эксперемент на дату 01.12.2003 /удаляю всего несколько первых месяцев/.
Делаю как здесь (13)

"сформировать доки остатков. заполненые, но непроведенные
откатить ТА и БИ на перед первым обрезаемым доком.
распровести. удалить в доках ТЧ.
потом пометить на удаление (возможно придется помечать и удалять порциями)
докатить ТА и БИ до первого документа остатков.
провести доки ввода остатков."

всё делается штатно, но при этом отчётность за 01.12.2003 в бухгалтерских отчётах пропадает:
http://prntscr.com/sliz1a
   evgpinsk_
 
26 - 22.05.20 - 09:36
И в строке состояния показывает не верный период БИ:
http://prntscr.com/slj2fd
както связано?
   Креатив
 
27 - 22.05.20 - 09:51
(0) Помнится был один вредный способ.
1. Формируешь документ ввода остатков.
2. Удаляешь файлы регистров и проводок.
3. В файле 1SJOURN.DBF ставишь удаляемым документам пометку на удаление.
4. Перепроводишь документы после даты свёртки.
5. Делаешь ТИИ.
   evgpinsk_
 
28 - 22.05.20 - 09:53
(25) "этом отчётность за 01.12.2003 в бухгалтерских отчётах пропадает:"
с этим разобрался. 
Отчёт "Оборотно сальдовая ведомость" в основной базе полетела почемуто не показывает итоги.
Остальные отчёты /тотже анализ счёта/ показывают обороты.

п.с. тестирую дальше
   evgpinsk_
 
29 - 22.05.20 - 09:55
(27) Основная проблема в пункте 4.

Насколько я понимаю, если мне и сейчас тупо перепровести все нужные оставшиеся документы заново, то все итоги станут верными.
Но хотелось бы решить задачу БЕЗ полного перепроведения нужных оставляемых документов
   Креатив
 
30 - 22.05.20 - 10:07
(29)Можно попробовать пропустить пункт 2 и 4. Если ТИИ удалит у помеченных движения, то всё хорошо. Но по времени неизвестно что получится.
 
 Рекламное место пустует
   Mihenius
 
31 - 22.05.20 - 10:14
(0) Я когда-то давно делал так
http://catalog.mista.ru/public/15114/

К сожалению, подробностей уже и не помню )

Обработкой из (12) тоже пользовался
   Mihenius
 
32 - 22.05.20 - 10:16
И перед сверткой еще подготовка простейшая нужна
http://catalog.mista.ru/public/15111/
   Креатив
 
33 - 22.05.20 - 10:22
(31) Так более изящно, если точно знать структуру регистров.
   Mihenius
 
34 - 22.05.20 - 10:27
1csql.ru 1c.proclub.ru dev.citykirov.ru уже не открываются. Ушли в лету
   hhhh
 
35 - 22.05.20 - 10:28
(29) там куча неточностей обычно и ляпов пользователей в этих документах, это жизнь. Поэтому итоги всё равно не будут верными. Эта проблема решается проведением инвентаризаций
   evgpinsk_
 
36 - 22.05.20 - 10:32
(35) Проблема не в пользователях, а в том, что гдето когдато мог поменять алгоритм проведения какихто документов. И перепроведение документов может пойти по новому алгоритму. И данные в оборотке станут отличными от текущих.
Скорее всего потом это будет сложно выровнять
   Ёпрст
 
37 - 22.05.20 - 11:03
(0) бухня ?
   Ёпрст
 
38 - 22.05.20 - 11:04
Если че, ТиИ запускать не надо.. никогда (особенно, если не знаешь, что оно делает)
   Ёпрст
 
39 - 22.05.20 - 11:05
И.. твоя база сворачивается минут за 5-10
   Ёпрст
 
40 - 22.05.20 - 11:13
   Ёпрст
 
41 - 22.05.20 - 11:14
Надеюсь создать доки /операции ввода останков сам смогёшь
   evgpinsk_
 
42 - 22.05.20 - 11:24
(40) Уже есть эта обработка )
Я писал в (0), что ей тоже пробую резать.
Вопрос в том, что и после этой обработки итоги падают
   evgpinsk_
 
43 - 22.05.20 - 11:26
(38) а что оно делает? )
Запускал, т.к. был шанс что исправит ситуацию.
ТиИ промежуточные итоги на конец каждого месяца не пересчитывает?
   Ёпрст
 
44 - 22.05.20 - 11:26
(42) :)))))))))))
Что значит падают ?
   Ёпрст
 
45 - 22.05.20 - 11:26
Тиии запускать не надо, от слова совсем
   Ёпрст
 
46 - 22.05.20 - 11:27
Если бухня, то прибить файло итогов (2 таблички), зайти монопольно и сделать полный пересчет бух итогов. Усё.
   evgpinsk_
 
47 - 22.05.20 - 11:28
(37) не совсем понимаю, что это значит?
   Ёпрст
 
48 - 22.05.20 - 11:28
И если есть ОС, то в запросах удаления воткнуть виды доков, которые удалять не надо (как и их периодику), такие как амортизация и прочий мусор, связанный с ОС
   Ёпрст
 
49 - 22.05.20 - 11:29
(47) Конфа какая ? Торговля? Комплексная ? ПУБ ? Бухия ?
   Ёпрст
 
50 - 22.05.20 - 11:29
Нетленка ?
   evgpinsk_
 
51 - 22.05.20 - 11:29
(44) У меня какойто полтергейст творится сейчас:
http://prntscr.com/sll6ri

один и тотже отчёт. 30 минут назад давал данные /в рабочей текущей базе с которйо ничего не делаю/. сейчас перестал давать
   evgpinsk_
 
52 - 22.05.20 - 11:29
(49) самописка
   evgpinsk_
 
53 - 22.05.20 - 11:31
(51) При этом Анализ счёта и другие отчёты отрабатывают нормально всегда:
http://prntscr.com/sll9kq
   evgpinsk_
 
54 - 22.05.20 - 11:35
Вполне возможно что проблема в (0) связана с тем, что сам по себе отчёт "Оборотно-сальдовая ведомость" глючит именно в этой базе, но не понимаю как такое возможно.
Этот же отчёт /сохранил его как внешний отчёт/ в других конфигурациях показывает обороты
   evgpinsk_
 
55 - 22.05.20 - 11:41
Запустил этот же внешний отчёт в этой же базе под другим сеансом и данные есть:
http://prntscr.com/sllguk
Что за ... ??
   Ёпрст
 
56 - 22.05.20 - 12:04
(51) Дык переиндексируй базу после свёртки, тупо удалив все *.cdx и зайти монопольно
   Ёпрст
 
57 - 22.05.20 - 12:05
(54)он не глючит
   Ёпрст
 
58 - 22.05.20 - 12:07
(52) короче, создай документы ввода остатков/операций и не проводи их, потом через (40) удаляешь лишнее, далее удаляешь все *.cdx и файлы бух итогов 1SBKTTL и 1SBKTTLC
   Ёпрст
 
59 - 22.05.20 - 12:08
заходишь монопольно, пересчитываешь бух итоги, проводишь доки останков и усё
   evgpinsk_
 
60 - 22.05.20 - 13:04
(57) Ну как же нет. На фото видно что один и тотже отчёт сначала открывается с данными, а  потом через какоето время в этой же базе уже пустой.
Сейчас буду пытаться искать причину.
   evgpinsk_
 
61 - 22.05.20 - 13:25
(60) Вроде разобрался отчасти, почему не мог получить корректные результаты резки. У меня косяк в базе по промежуточным итогам идёт.
Вот первый месяц в котором есть данные: октябрь 2003 года. И уже на конец этого месяца, промежуточные итоги не верные, это видно в отчёте на ноябрь 2003:
http://prntscr.com/slnnrx

Правда это не объясняет , почему отчёт "Оборотно-сальдовая ведомость" то показывает то не показывает данные.
   Злопчинский
 
62 - 22.05.20 - 13:26
(14) вот я вчера и косячнул так.. бух залезла взад, я пересчитал. и все уползло на точки. до даты свертки. сижу исправляю ;-)
   Злопчинский
 
63 - 22.05.20 - 13:28
(19) я вот как-то не в теме, ка кобрезать оборотный регистр, чтобы остались обороты за предыдущий период...
   Злопчинский
 
64 - 22.05.20 - 13:29
(21) ну так у тебя любое действие по изменению влечет пересчет и регистров и БИ если ТА/БИ не откатить. поэтому и долго
   Злопчинский
 
65 - 22.05.20 - 13:32
(29) никакие документ после свертик перепроводить не надо. если входящие остатки сформировал правильно - этого достаточно. ну по регистрам стопудово так. по БИ - может что и надо, но не думаю..
   Злопчинский
 
66 - 22.05.20 - 13:32
(30) если помечать на удаление штатано - движения удаляются сами штатно.
 
 Рекламное место пустует
   Злопчинский
 
67 - 22.05.20 - 13:35
(32) нихрена этой подготовки не надо. все нужные документы - которые фигурируют во входящих остатках - останутся в базе внепроведенном виде, без ТЧ. этого вполне достаточно. описанная "подготовка" - это уже для красоты и для того случая если надо перепроводить документы от после даты свертик до сейчас.
   tgu82
 
68 - 22.05.20 - 15:37
(0) Все-таки для ТИС обработка СверткаИБ классная вещь хотя конечно елси через Универсальный двигатель регистров - это конечно более гибко
   tgu82
 
69 - 22.05.20 - 15:39
(68)+ Просто движения через Унисерсальный двигатель регистров можно потом творчески подработать а вот свертку уж ене подработаешь
   GreyK
 
70 - 22.05.20 - 16:04
(68) Да ничего в ней "классного" нет, она работает при "идеальном учете", с соблюдением всех правил учета, даже при постоянном восстановлении последовательности партии уходят в минуса, если юзвери работают "задним числом", и это никак стандартными средствами не лечится.
   Cthulhu
 
71 - 22.05.20 - 16:04
(67): только я бы поостерегся чистить таб.части у всех помечаемых на удаление документов. данные строк этих документов "вдруг" могут понадобиться позже даты свертки (например, в алгоритмах авто-заполнения более поздних документов по табличным частям цепочки документов-оснований... или, например, в отчетах, использующих таб.части документов для "разворачивания" итоговых свернутых оборотных показателей, и т.п.)
   Cthulhu
 
72 - 22.05.20 - 16:08
(68) любая свертка, которая перерассчитывает движения документов - нихера не "классная", т.к. не гарантирует точное совпадение оборотов до/после свертки (и истории - но там отдельная песня с переносом всех привязанных к удаляемым документам установок в установленные вручную, и с прочими плясками).
   Злопчинский
 
73 - 22.05.20 - 17:26
(71) в типовой ТиС такового нет. ТЧ можно тупо чистить без проблем.
   evgpinsk_
 
74 - 22.05.20 - 18:37
(51) Ребята, кто попытается объяснить этот полтергейст?
http://prntscr.com/sll6ri
Обычный типовой отчёт то выдаёт данные то следующим запуском может выдавать пустые цифры.
   GreyK
 
75 - 22.05.20 - 19:00
(74) Что объяснить? Что у тебя ТИИ уже не делалось давно или то, что ты ещё там работаешь?
   Djelf
 
76 - 22.05.20 - 19:08
(75) На ТИИ он умрет ждать, в (0) он об этом как раз и писал, а ты это прочитал?.
Лучше попробовать выгрузить/загрузить, это раз в 100 быстрее. Либо грохнуть все rg.*, примерно так же будет.
   Злопчинский
 
77 - 22.05.20 - 19:17
суко. касса. на начало. 0.006
аж слезу выбило.. ;-)
   Djelf
 
78 - 22.05.20 - 19:28
Да ты просто Экспериментатор :) https://www.youtube.com/watch?v=pgolaktMXbU
Обычное дело при обрезке базы...
   evgpinsk_
 
79 - 22.05.20 - 19:42
(75) Врде ж все видно на фото по ссыолке, в 19-40 я запускаю отчёт и он показывает все данные, затем запускаю его заново в 19-41 и он данные уже не показывает
   ChMikle
 
80 - 22.05.20 - 20:01
(78) :)))))) пиши исче
   Злопчинский
 
81 - 22.05.20 - 21:11
(78) Почему это обычное дело?
как вы умудряетесь все время на какие-то грабли наступать. напролом несетесь?
я то от незнания наступаю, но сколько раз резал ну не было такого чтобы какие-то адские косяки.. не припомню..
   evgpinsk_
 
82 - 23.05.20 - 20:54
(74) Актуально. Без оборотки нет возможности сверять порезанную базу с исходной
   opus70
 
83 - 23.05.20 - 21:09
1.Сформировать документы ВводаОстатков в текущей базе
2.Перенести их в пустую базу (http://catalog.mista.ru/public/195955/)
3.До перенести цены и так далее через ole
   Ёпрст
 
84 - 23.05.20 - 21:40
(74)переиндексируй базу, зайди монопольно, "полтернейст" исчезнет
   Ёпрст
 
85 - 23.05.20 - 21:41
Если нужны подробности,
ознакомься
http://catalog.mista.ru/public/15577/
   evgpinsk_
 
86 - 24.05.20 - 14:07
(84) Не помогло, всё-равно пустые ячейки:
http://prntscr.com/smsaft
(85) Не совсем разобрался, просто блокнотом нужно отредактировать Seven.dll и DBEng32.dll найти контекст “Kernel32.dll” и заменить двойку на тройку?
и оместить в каталог исполнительных модулей 1С файл Kernel33.dll

После этого при запуске 1с ругается на испорченную dll
   Ёпрст
 
87 - 24.05.20 - 14:09
(87) а есть уверенность что за 1 день там что-то было ?
   Злопчинский
 
88 - 24.05.20 - 14:24
(87) выше приводил скрин он где заполнено.
   Злопчинский
 
89 - 24.05.20 - 14:25
но что-то мне мыслит что но просто суетится.
ну и версия платформы, надеюсь, 27..?
   hhhh
 
90 - 24.05.20 - 14:37
(88) непонятен сам подход. Если у него база начинается с 2017 года, почему в 2009м должно что-то быть.
   Злопчинский
 
91 - 24.05.20 - 14:40
(90) логично!
   Ёпрст
 
92 - 24.05.20 - 14:54
(88) неа, там период другой
   ДенисЧ
 
93 - 24.05.20 - 15:04
(90) А почему бы и нет? У меня тут внезапно обнаружились документы за 203 год.... Да, не 2003, а...
   ДенисЧ
 
94 - 24.05.20 - 15:05
Правда, они без движений, но...
   Злопчинский
 
95 - 24.05.20 - 15:21
(94) фу, неряха... ;-)
   ДенисЧ
 
96 - 24.05.20 - 15:23
(95) Тю на вас, те документы созданы были, когда я находился от этой базы в 800х километрах и 10 годах... )))
   Злопчинский
 
97 - 24.05.20 - 15:24
(96) фу, бяка-2!
   ДенисЧ
 
98 - 24.05.20 - 15:30
(97) Уйди, противный. Когда нашёл - удалил.
   evgpinsk_
 
99 - 24.05.20 - 16:02
(87) Несколько раз выкладывал скрины )
в том числе и там где полтергейст (51)
http://prntscr.com/sll6ri
на скрине видно одновременно два отчёта, которые были запущены один за одним.
Первый выдал данные, через 10 секунд ничего не меняю и открываю тотже отчёт и он уже пустой
   evgpinsk_
 
100 - 24.05.20 - 16:03
(90) Откуда взят 2017? Сейчас база с 2003 года
  1  2   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.