Euroset1
Антон Володченко

(1) Да скачивают люди раз в месяц в среднем. Я вот регулярно ей пользуюсь.

И соответственно V8Exchan83.epf - для конфигураций на обычных формах. - опечатка, поправьте..

(17) не совсем понимаю, как такой способ поможет перенести данные журнала. Я здесь вижу только способ создать пустой журнал.

(16)
(17)
Коллеги. Обработка создавалась в те времена, когда этого сделать было нельзя. Да и на старых релизах 8.2 (на которых сидит очень много) до сих пор так.
Ее предназначение было не только перевод, но и объединение журналов. То есть Вы могли сначала неудачно перевести базу, а потом еще и проработать на ней неделю. А потом ой, а мы же журнал забыли, ну и как бы других вариантов кроме объединить или забить, не будет. На моей практике была неделя, за которую базу переносили между несколькими машинами, так еще и между кластерами. Естественно, журналы штук 5 файлов lgd скопилось. Мы легко превратили это все в один файл и подсунули базе.

Что касается штатных методов, то спасибо 1С, что через сто лет они изволили продвинуться в этом направлении. Опять же, объединением разных кусков журнала там не пахнет. Но если Вам нужно всего лишь перенести базу и время не поджимает именно в момент переноса (например, вся ночь впереди), то пользуйтесь конечно типовым функционалом. Он должен работать побыстрее, т.к. там не требуются танцы с бубном для преобразования кодировки с использованием диска.

(190) у меня в каждом расширении форм 50 вынесено...

(187)
Мне кажется, что у Вас была ситуация совсем другая. У пользователя стоял отбор в динамическом списке, не совместимый с жизнью, такое бывает. Бывает даже что пользователь но не индексируемому полю жмякнет, у него виснет на ожидании сортировки и все, а сервер корячится. А своими действиями Вы могли просто передернуть его настройки формы и "поправить" это дело неявно.

Меня интересует немного другой случай. Когда я запускаю безобидную обработку, которая на других даже более слабых серверах выполнялась без ошибок, а в течение цикла на абсолютно рандомном месте вываливается то, что описано в названии темы. И копия той же базы на другом серваке исправно справляется с полным циклом. А тут, секунд 50 после запуска и бац. В том числе и в фоне, то есть это не обязательно пользовательский сервер, под юзер1с тоже самое.

(185) Коллега, подскажите, пожалуйста, пару моментов:
1. Как именно локализовали одно конкретное расширение, и тем более, конкретные метаданные в нем? На какой "логике" основывался поиск?
2. Собирать расширение заново - не могли бы Вы по-подробнее описать, что под этой фразой кроется?

(1)
1) ТИИ не проканает, ради такой базы тебе от недели до месяца компанию нужно останавливать.
2) в SQL менеджере посмотри отчет по верхним таблицам. найди или сделай обработку, которая подскажет тебе связь имен этих таблиц с твоими метаданными.
3) Ищи регистры сведений ненужные, которые не используются. Может, логи какие-то кто-то делал и забыл автоочистку поставить.
4) Ищи какие индексы можно убрать. Иногда самопальные метаданные идексируют тупо по всем полям.
5) Посмотри есть ли в базе версионирование. Если включено, то отключай нафиг и удаляй все эти копии объектов нафиг.
6) Посмотри есть ли всякие замеры времени. Их тоже можно почистить.
7) Посмотри как настроено хранение файлов. Если не на внешних томах, то тогда у тебя пол базы - это всякие сканы накладных, договоров и счетов. Переноси на отдельные тома штатными средствами.
8) если все это не помогло снести лишние 3 терабайта, то ищи новую работу =)

(26) какой конкретно релиз у вас?

(22) если отказаться от спецсимволов и вводить в шаблон теги монотонно без копипоста и за один раз типа ДатаПолученияДоговора или НомерСтроки, то этот текст будет лежать в одном теге гарантированно. Мне норм. Не вижу основания использовать скобки для тегов теперь, обладая этими экспериментальными данными =)