Удаление записей dbf-файла, приближающегося к 1ГБ
 

Размер файла движений регистра "ОстаткиТоваров" приближается к 1 Гб и превысит его примерно в середине сентября (в базе 2013 и 2014 гг, когда принимали решение не переходить в новую базу в начале 2014, была надежда, что дотянем до конца 2014).
Вариант с библиотекой Kernel33.dll известен, но смущает следующая часть комментария к ней "Внимание!!! К базе данных не должно быть обращений из модифицированной и не модифицированной 1С одновременно, т.к. это приведет к порче базы данных." - в основном пользователи работают через терминал, но 100%-ой уверенности что никто и никогда не зайдет локально из не модифицированной 1С нет и рисковать не хочется.
Была мысль перейти на бесплатную версию sql, но руководство отказалось выделить 100 тыр (столько сейчас 1С желает за sql-версию компаненты "оперативный учет").
Вариант создать новую базу на 01.09.14 и сформировать остатки и нужные доки прошлого периода сложности не представляет, но это будет означать что данные 2014 будут в двух базах, а эта перспектива (естественно) вызвала бурную реакцию пользователей.
Я собирался сделать непроведенными документы за 2013 и создать остатки на 31.12.2013, но появилась мысль: а что если просто удалить в проблемном файле записи за 2013 и создать "ввод остатков товаров" (на случай необходимости полного пересчета
итогов) на конец 2013? Сделал, проверил базу тестированием, сравнил движения по нескольким периодам - вроде все нормально.
Но может у подобных способов есть "подводные камни", на которые я пока просто не наткнулся? Или наоборот такой метод широко используется и волноваться совершенно не о чем?

Удаление прошлых записей и создание новой базы - это одно и то же, вообще-то.
За полтора годочка всего-то регистр стал гиговым? А закрывать не пробовали?
P.S. Некоторые чудаки, правда, налаживают дисциплину, и не имеют таких проблем...

1-VZ > "одно и тоже" - в принципе да, но методы могут быть разные, я частично никогда ранее записи не удалял из файлов документов и регистров при создании новой базы, а удалял все файлы документов и регистров оставляя справочники и т.п и формировал обработками остатки.
У наладивших дисциплину файлы более 1ГБ не растут, они (файлы) становятся дисциплинированными? ;-)

1-VZ >регистр движений же, не остатков. чего там "закрывать"?

0-ADV >нормальный способ, не боись

Не осилил столько букв. Если создаются документы начальных остатков, то как не называй, хоть слоном - это "свертка базы". А дальше уже техника этой свертки. Там возможны варианты. Стандартный подход предполагает как раз пометку на удаление, а затем удаление помеченных с учетом ссылочной целостности, а не "а не сделать не проведенными". А вот помечать можно по разному, я, например, использую прямые запросы к журналу и регистрам.

(0) А вот этот способ решения проблемы 1 Гб не хотите проверить: [url]http://www.wirth.ru/load/v7dbnet/1-1-0-2[/url]

6-Ткачик >интересный вариант, спасибо)) если не в этот раз, то на будущее может пригодится - фирмы с которыми я сотрудничаю пока с 7.7 уходить не планируют

(0) > но 100%-ой уверенности что никто и никогда не зайдет локально из не модифицированной 1С нет и рисковать не хочется.
.
- а у вас там что - бардак и махновщина? кто угодно может установить что угодно и запустить..? Чем занимаеются тогда Итшники - быдлокодят под примотром начальников?
.
у себя - стоит этот патч, все работает нормально.

8-Чучундер > "кто угодно может установить что угодно и запустить..? " - нет. "Чем занимаеются тогда Итшники " - можно я не буду перед вами отчитываться? Спасибо.
"у себя - стоит этот патч, все работает нормально." - не думаю, что это факт дает вам право высказывать в адрес других предположения типа "быдлокодят"

это чего там такое делается, если за короткий период - 1гб?



"в основном пользователи работают через терминал, но 100%-ой уверенности что никто и никогда не зайдет локально из не модифицированной 1С нет и рисковать не хочется"

а если не выставлять базу в сетку - никто и не зайдет


мы свертку базы делаем просто - спец документ с периодом, в него грузятся все удаляемые доки построчно (с указанием номера и даты исходных доков - это для поиска за прошлые периоды с помощью спец обработки). Движения этого спец дока делаются сводно по строкам на конец периода

8-Чучундер > ""кто угодно может установить что угодно и запустить..? " - я там приходящий (1-2 раза в неделю + удаленно), 1С устанавливает новым пользователям сисадмин. Пользователи работают как через терминал (в основном) так и локально, на это есть причины.
Предположим, что админ добросовестно(ничего не забыл и не пропустил, хотя все мы люди) прошелся по всем ПК (около 20) пропатчил или деинсталировал локальные 1С и база работает с патчем. А теперь представим, что нынешний админ уволился - мне об увольнении админов обычно сообщали ПОСЛЕ прихода нового. И новый по чьей-то просьбе сделал локальное подключение. Может ситуация и не слишком вероятная, но исключать ее я не готов. Так наверняка и иные ситуации которые мне не приходят сразу в голову могут быть.
Если б ситуация решалась ТОЛЬКО установкой kernel33.dll или иные варианты стоили бы много денег или трудозатрат - тогда конечно использовали бы патч и постарались бы ужесточить меры борьбы с потенциально возможными и имеющимися (как и у большинства, думаю ;-)) проявлениями "бардака и махновщины".

10-Helen1986 > "это чего там такое делается, если за короткий период - 1гб?" - торгуют там (в основном торговые представители (20 - 25 чел) развозят по магазинам) мелким оптом достаточно большой ассортимент. Повторяю, (а то многоуважаемый VZ уже намекал насколько я понял на незакрывающиеся остатки регистра) - разросся файл ДВИЖЕНИЙ регистра, не остатков.
"а если не выставлять базу в сетку - никто и не зайдет" - там среди прочего фискальный регистратор и нескольким поколениям админов (как кстати и еще на одной фирме совсем другим админам) через терминал его подключить не удалось. Кроме того урководство жмется на дополнительные терминальные лицензии (понятно, что в масштабах фирмы это копейки, но решаю не я) и в связи с этим было принято решение, что некоторые пользователи работают локально.

[quote=ADV;36361063]там среди прочего фискальный регистратор и нескольким поколениям админов (как кстати и еще на одной фирме совсем другим админам) через терминал его подключить не удалось. Кроме того урководство жмется на дополнительные терминальные лицензии (понятно, что в масштабах фирмы это копейки, но решаю не я) и в связи с этим было принято решение, что некоторые пользователи работают локально[/quote]


криворукие админы. Фискальник прекрасно цепляется.
одноэсник же, который допускает какой гибрид (терминал + сетевые) - это отдельно стоящий иди... куда то идет

а куроводство - сами себе злобные буратины

Очень странно, что разросся файл движений. Движения, в отличие от остатков, не переносятся в следующий период. Может просто сделать упаковку базы? Может просто документы часто перепроводят и этот распухший файл полон удаленных записей ?

я бы вообще сделала на копии выгрузку загрузку для полной очистки дбф от мусора

15, 16. делал, размер проблемного файла изменился незначительно. "Странно что разросся" - просто объективно много движений, в чем вы видите странности? Следующий по объему файл базы (но он не дорастет до конца 2014 до ГБ) - многострочные части накладных.

Интересно, это только мне высказывания Helen1986 и ей подобных, в которых речь идет о неких Великих Тайных Знаниях, Умениях и Окуительных подходах к решению проблем напоминает обращение небезизвестного М.Кибальчиша к своим политическим оппонентам: "А больше я вам ничего не скажу! А самим вам, проклятые буржуины, во век не догадаться!!!!"
З.Ы. это не по текущему сабжу такое впечатление, в нем Helen1986 пока что на удивление толеранта)) Впрочем, "еще не вечер"...

О Великих Тайных Знаниях и Умениях речь не идет.

Это все обязанности админов, и я в них не лезу, своих дел хватает, и всего не освоишь.

Но у нас в центральном курятнике висит с десяток фискальников в терминале в базе оперативного управления (управленческая база) - все работают в терминале, по локалке и с инета.

И такие же рабочие места с фискальниками есть и филиалах (там свои сервера). Особых проблем не было. Часть серверов с терминалом и фискальниками перешли к нам по наследству при покупке филиалов

на самом деле хорошего админа, способного поднять и [u][b]правильно[/b][/u] настроить сервер с терминалом - еще поискать надо.

а недостроенные сервера от мальчиков-побегайчиков для 1це - сплошь и рядом. у ТС - типичный случай

15-USSR >дык работают люди. у меня в одной базе вообще файл DT к пределу подошел

18-ADV >хорошие каналы связи - вот самая боевая магия. потому как настроек чудесных у RDP - раз, два, и обчелся.

12-ADV > Вообще-то, я намекал именно на "движения". Мне вовсе не могло прийти в голову "остатки": это обозначает одного порядка с миллионом обороты по номенклатуре, т.е. по [em]наименованиям[/em]. Для таких оборотов очень странно выглядит экономия в "100 тыр" (сабж).
В то время, как безоглядное лазанье в записи через "заднее число" хорошо известно своими последствиями.
7-ADV > Чтоб несколько охладить [em]энтуазизм[/em] предлагаю взглянуть на дату релизов.
Кстати, почти наверняка это вызовет большущую проблему, когда таки будете вынуждены слезть с древних ДБФ.
И то, что ХП уже не лицензируется - озабоченности не вызывает?
Хотя... Следующий год - этож очень далекое будущее...

19-Helen1986 > "висит с десяток фискальников в терминале" - ну хз, может и правда в это вопросе наши админы слабы, не знаю. Хотя может разные типы ФР с терминалами по разному работают (у нас "феликсы" и тут и в другой упомянутой выше конторе)?
21-Управление торговлей 11 > DT - в п.17 я об аналогичной ситуации упомянул.
23-VZ > мой "энтуазизм" в п.7 вполне возможно объясняется недостаточно глубоким знакомством с ПО, предлагаемым в п.6)) но что релизы там нескольколетней давности я заметил

+ к 24. "разные типы ФР с терминалами по разному работают" - имелось в виду "взаимодействие одних ФР терминалом настроить проще, чем для ФР другого типа".

[quote=Helen1986;36360999]это чего там такое делается, если за короткий период - 1гб?[/quote]
2 оператора, сидящие в наушниках на телефоне, забивают заказами до гига за 1 год в лехкую. Приходилось базу каждый год резать, правда я резал когда уже к 2-м гигам подбиралось ;)

26-Кондрат2 >
- Умеете печатать со скоростью 60 знаков в минуту?
- Умею.
- А со скоростью 120 знаков в минуту?
- Умею, но такая фигня получается...

Сделать остатки на начало года, а потом загрузка/выгрузка в идентичную конфигурацию начиная с документа остатков

(11) ну я ж грю, бардак и махновщина..
если админы увольняются/принимаются, старый алмин ничего не сдает/не вводит в курс дела нового - а так как 1Ска является "системообразующим" фактором - то первым делом админа и того кто заботится об устойчивости системы - повесит в админской плакат с большими буквами про 1С... ;-)

Как вариант можно еще сделать "свертку" - движения по остаткам за день сконсолидировать: все движения одной номенклатуры по всем документам за один день - показать одной строкой. для статситики - вполне достаточно - редко кто анализирует мельче чем за день...
.
такая свертка я думаю даст экономию раза в 4-5 как минимум...

(26) гонишь, из расчета 8часового рабочего дня, 365 дней в году, по 2 секунды на ввод одной строки, на примере типовой ТИС - запись движений по регистру заявок = 88байт, один оператор = 441Мб. в реальности - все помедленнее будет примерно вполовину - доки еще проводить надо... не, если там у вас запись по 300-500 байт взаявке (что вполне может быть) - ну тады ой...

31-Чучундер > Чего это "ой!"? Простейший вопрос "сколько живет заявка" убивает всю эту демагогию.

(32) "сколько живет заявка" - срок жизни заявки не влияет на количество записей в регистре движений (для упрощения принимаем что корректировочные заявки отсутсвуют или незначительны).
.
или я что-то не понял?

а кому это надо - убивать заявки?
к тому же неизвестно, сколько заявка будет комплектоваться/доставляться, может за год вперёд заказали, да и отгрузка поэтапная

33-Чучундер > Это реакция на "[em]не, если там у вас запись по 300-500 байт взаявке (что вполне может быть) - ну тады ой[/em]" ;)
Имел ввиду, что [по крайней мере] удовлетворенным заявкам жить не надо.
А для неподтвержденным авансом можно и задать срок сосуществования. О котором можно без излишней скромности сообщить клиенту.
34-Зелёный тролль > Решается требованием в определенный срок закинуть авансик ;)

Ни понял... В одну и ту же базу - люди ходят и терминально и по сети????
Начальника ИТ-отдела - уволить. Гендира - депремировать квартально. ИМХО.

35-VZ > ну да, осталось добавить документ "Требуем авансик" в конфу

37-Зелёный тролль > А нафига? Достаточно в счет прописать фразу "Счет действителен до ..." :)

ну-с, сегодня меня порадовали...
.
пришел 1сник, который у нас ведет бухню с вопросом: что делать, файл достих двух гиг...
.