В блоке не обнаружен файл пмк
Обновлено: 14.05.2024
Имеются некоторые блоки, взятые не с моего листа и не мною собранные. Забрал их к себе - работают. Пытаюсь создать на их базе палитру инструментов для себя, получаю в ответ ошибку следующего содержания:
"Блок <название блока> не найден в исходном чертеже. Исходный чертеж, если он открыт в редакторе, следует сохранить"
Как это победить или в каком направлении копать? И таких блоков не раз и не два.
В них увидишь путь до файла-донора блока. Открой файлик и посмотри, есть там этот блок или нет.
Инженер-конструктор ГТС (а по факту ПГС) с 2011 г.
От 2006 работаю с политрой инструментов. В первые слышу о таком. Вы гдето что то не правильно делаете. Изначально если блок присутствует на чертеже файл нужно сохранить а потом вставленный блок добавить в политру. И второе из вашего вопроса не ясно это происходит когда вы блок тащите на политру или когда вставляете блок с политры.. перед тем как тащить, нужно каждый раз сохранять чертёж!
. Причём тащить надо из одного и того же чертежа, чтобы у палитры был один источник!
Последний раз редактировалось VitalyAF, 04.12.2013 в 17:37 .Инженер-конструктор ГТС (а по факту ПГС) с 2011 г.
Вот оно как. Достаточно печально. А каким-то образом сделать чтобы для перенесенных "из вне" дин.блоков в рабочий файл в качестве источников для палитр(а может и блоков, кто его знает - где еще это всплыть может) начал считаться рабочий файл, а не файл-исходник, где блок был создан - возможно? Вот оно как. Достаточно печально. А каким-то образом сделать чтобы для перенесенных "из вне" дин.блоков в рабочий файл в качестве источников для палитр(а может и блоков, кто его знает - где еще это всплыть может) начал считаться рабочий файл, а не файл-исходник, где блок был создан - возможно?Что бы к блокам политры был всегда доступ нужно иметь отдельный файл для блоков и из него компоновать политру. А из рабочих это проблемно. Переместил, изменил имя и всё путь потерян и блок с политры не загружается и где искать этот файл иногда трудно вспомнить. Я для блоков политры держу отдельный файл.
Об этом уже сказали выше. Нужно сделать сохранение файла, а затем тащить блок на политру.Инженер-конструктор ГТС (а по факту ПГС) с 2011 г.
Понятно, спасибо за ответы.Есть над чем еще работать автодеску в плане юзабилити интерфейсов. С чего бы вдруг? Блок откуда-то надо копировать. Соответственно место, "откуда копировать", должно быть где-то определено - это раз, и содержать запрашиваемую информацию - это два. Так что все логично. __________________
| --- Обращение ко мне - на "ты". Все, что сказано - личное мнение. |
Есть над чем еще работать автодеску в плане юзабилити интерфейсов. А Вам так не початый край над чем работать в плане изучения Автокада.
| Есть над чем еще работать автодеску в плане юзабилити интерфейсов |
У меня ситуация такая, что потерялась связь с исходными файлами .dwg, так как общие палитры и исходники лежали на сервере. Количество палитр весьма большое с разделителями и текстом в группах палитр. Файлы в .atc в отдельных файлах, в связи с этим менять их путь редакторами не предоставлялось возможным.
Я, в итоге, сделал следующим образом: добавил все палитры из групп экпортом-импортом в общую единую палитру без исходного разделения на "новые группы", импортом из .xpg.
Потом уже общим выбором всех объектов через ctrl+A в свойстах объекта на непосредственно самой панели палитр (ctrl+3) изменил исходный серверный путь .dwg на локальный.
Кстати, еще заметил, что при открытии файла блока в .dwg любого объекта палитры, связь с другими объектами из нее не теряется. Т.е. теоретически можно работать из вычищенного любого файла блока, путь в таком случае не обрывался.
Итак, перед нами "мёртвая" файловая база. Задача, которая стоит перед нами на текущий момент - всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго "ныряют" в содержимое файла базы в hex-редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой-нибудь инструмент, и получив неудачу, выдают заключение: "База не подлежит ремонту". Лично я считаю, что к услугам hex-редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению.
А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1С предоставляет, как минимум, два штатных способа. Рассмотрим их поподробнее.
1. Утилита chdbfl.exe из поставки 1С:Предприятие. Запускаем её с установленной галкой "Исправлять обнаруженные ошибки".
Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой-то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких-то видов, и просто "выкидываем". Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой.
Например, "Поврежден заголовок файла базы данных" чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex-просмотрщику или редактору, если в начале файла сигнатура 1CDBMSV8 на месте, значит, проблема только в поле длины). "Повреждено содержимое внутреннего файла " означает, что в корневом объекте существуют "битые записи", с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее.
1С:Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются:
V8USERS - таблица с данными пользователей (для баз версий 8.2 и выше)
DBSCHEMA - схема (структура) БД
_USERSWORKHISTORY - история работы пользователей
_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS - хранилища различных настроек
а также системные таблицы-каталоги:
PARAMS - содержит файлы с параметрами БД
FILES - содержит прочие системные (служебные) файлы
CONFIG - содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID.GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной).
CONFIGSAVE - содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы-каталоги являются, по сути, аналогами каталога в обычной файловой системе, т.е. являются хранилищем некоторого набора файлов, и имеют следующие поля:
FILENAME - имя файла
CREATION/MODIFIED - дата создания/изменения
ATTRIBUTES - атрибуты
DATASIZE - размер файла
BINARYDATA - содержимое файла (двоичные данные)
Теперь мы понимаем, что записи в ТЖ типа
22:42.0169-1,DBV8DBEng,2,process=1cv8,Trans=0,Func=selectFileName,FileName=ibparams.inf
22:42.0170-3,DBV8DBEng,1,process=1cv8,Trans=0,Func=readFile,CatName=Params,FileName=ibparams.inf
означают чтение файла "ibparams.inf" из таблицы PARAMS.
3. Открываем нашу базу при помощи утилиты Tool_1CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т.д.) поддерживается автоматическая распаковка содержимого BLOB-полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. 1 и 2, ограничивается именно системными таблицами).
При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями "OG" - их наличие означает, что крах базы произошёл при ТиИ или реструктуризации (в процессе выполнения этих операций 1С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы.
При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями ".new" - их наличие означает, что крах базы произошёл при обновлении конфигурации БД.
Также утилита позволяет сохранить конфигурацию БД в cf-файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации.
5. Загрузка базы в систему восстановления баз 1С restoration-base-1c8. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 230 Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался - закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1С, то все данные исходной базы загружаются также в базу 1С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из-за ограничений формата). Тем не менее, проект является свободным, с открытым кодом, доступным для изменения и доработки, поэтому не могу не упомянуть про него.
Загрузив нашу базу в систему restoration-base-1c8, мы можем иследовать список таблиц:
а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:
Просмотр записей таблиц, к сожалению, не реализован.
На этом наш список, а также сам этап обследования заканчивается. Аккуратно фиксируем и систематизируем всю собранную информацию, которую мы будем использовать далее, в процессе "лечения". Конкретные, наиболее типичные проблемные ситуации и способы их устранения будут рассмотрены в следующих статьях.
«Поле объекта не обнаружено» - ошибка, которая встречается довольно часто при работе с программными продуктами 1С:Предприятие. Часто она возникает после обновления программы. Рассмотрим подробнее, в чем ее причины и как с ней бороться.
1. Ошибка в файлах внешних обработок, отчетах и доработанных программных продуктах.
Чаще всего ошибка возникает после обновления в файлах внешних обработок, отчетах, либо дописанных блоках программы, – в том функционале, который не входил в основную поставку 1С. В данном случае ошибка «Поле объекта не обнаружено» означает, что программа пытается обратиться к полю, которого больше нет или имя которого было изменено.
Как правило, данные в программных продуктах 1С не исчезают «в никуда», если некое поле было удалено разработчиками, значит информация, которую оно хранило, перенесена в другое поле (реквизит, переменную, и т.д).
Второй причиной может стать ошибка при проведении обновления – и это относится только к доработанным конфигурациям и не затрагивает внешние отчеты и обработки. В этой ситуации специалист при обновлении случайно «затер» дописанное поле (реквизит, переменную, и т.д.). Понять это можно, сравнив обновленную базу с копией базы, и сравнив конфигурацию текущей базы с типовой (Конфигурация – поддержка – сравнить, объединить). Решение может зависеть от того, что конкретно было «затерто». Но как правило, если ошибка была допущена при обновлении, нельзя знать наверняка - единственная ли это ошибка. Поэтому наилучший выход – восстановить базу из копии и провести обновление снова.
Если вы точно уверенны, что работаете с неизмененной конфигурацией, и ошибка возникает при работе исключительно с типовым функционалом, тогда есть несколько способов, которые могут помочь решить проблему.
2. Ошибка «Поле объекта не обнаружено» в 1С 8.3 при обновлении неизмененной конфигурации.
Иногда ошибка «Поле объекта не обнаружено» в 1С 8.3 возникает при обновлении типовых конфигураций. Причин и решений ошибки может быть несколько:
1). Изменение платформы.
Ошибка может возникать, когда в обновленной конфигурации используются основные механизмы платформы, которые в используемой версии платформы еще не реализованы. Ситуация может быть и обратной. Поэтому одно из правильных решений – обновить платформу до последнего релиза 1С 8.3 либо попытаться использовать более старый, но подходящий релиз платформы.
2). Тестирование и исправление 1С
Во время работы с базой и во время ее обновления бывают ситуации, когда база данных может быть повреждена. В таких случаях базу нужно чинить. Сделать это можно с помощью Тестирования и исправления 1С внутри самой конфигурации (в конфигураторе открыть Администрирование - Тестирование и исправление). Перед любым тестированием обязательно нужно сделать копию базы данных. При тестировании должны стоять галки «Проверка ссылочной целостности информационной базы» и «Проверка логической целостности информационной базы», имеет смысл еще поставить галку «Реструктуризация таблиц информационной базы». Далее нужно выбрать поле «Тестирование и исправление». В блоке «При наличии ссылок на несуществующие объекты» выбрать пункт «Очищать ссылки». А в блоке «При частичной потере данных объектов» выбрать «Удалять объекты». Затем нажать кнопку «Выполнить».
Если это не помогло, можно также попытаться использовать утилиту сhdbfl. Она находится в папке bin в установленной платформе.
3). Очистка настроек пользователей
Затем нужно открыть подменю «Персональные настройки пользователей» и выбрать пункт «Очистка настроек».
Здесь можно выбрать – очистить ли настройки всех пользователей или нескольких. Также можно выбрать конкретную настройку или очистить все настройки (очень удобно, если знаете, у какого пользователя и в каком месте вылетает ошибка).
4). Ошибка разработчиков
Можно подождать следующего обновления или «обновиться» на чуть более старый релиз программы. Как правило, совсем уж явные ошибки разработчики исправляют быстро.
Для запуска 1С в клиент-серверном режиме нужно ДВЕ лицензии: одна серверная для запуска сервера 1С:Предприятия, вторая клиентская для запуска клиентского приложения (а для запуска файловой базы нужна только клиентская лицензия, а серверную устанавливать не нужно вовсе) .
Судя по данному тексту вы получили лицензию на СЕРВЕР.
Не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия!
Данный текст говорит о том, что 1С не видит лицензию на запуск КЛИЕНТА.
Файл программной лицензии не предусматривает возможность запуска клиентских приложений 1С:Предприятия или внешних соединений:
file://C:/ProgramData/1C/licenses/ХХХХХХХХ.lic
100% что это файл той самой лицензии на сервер 1С, который вы только что получили.
Уточнить можно открыв файл лицензии текстовым редактором, например, блокнотом - в конце файла будет информация о лицензии в человекочитаемом виде.
Т.е для работы вам теперь ещё надо получить клиентскую лицензию.
Для полного понимания советую почитать инструкцию по повторному получению лицензии 1С с разборами ошибок и примерами (кстати, ваш случай там тоже есть)
Как восстановить программную лицензию 1С:Предприятие 8
P. S.
Кстати имя файла затерли совершенно зря - оно представляет собой дату и время получения лицензии, никакой уникальной идентифицирующей информации в имени файла нет, например, активированная сегодня лицензия будет вида 202110131012345.lic, где первые 8 цифр - это дата 2021.10.13, а следующие 6 цифр - это время ЧЧ.ММ.СС.
Добавлю еще один момент - активировать многопользовательскую программную лицензию на сервере имеет смысл только в трех случаях:
1. Если будут клиент-серверные базы под SQL, в этом случае лицензии клиентам будет выдавать сервер 1С:Предприятия;
2. Если базы опубликованы на веб-сервере (Apache или IIS), в этом случае лицензии будет раздавать модуль веб-сервера;
3. Если сервер терминальный, в этом случае клиенты при подключении по RDP/RemoteApp смогут получить лицензии из файла сами.
Если же файловые базы запускаются на клиентских машинах локально или базы располагаются на файловом сервере просто в расшаренной папке, то активировать многопользовательскую лицензию нельзя, т.к. раздавать ее клиентам по сети будет некому. В этом случае необходимо активировать однопользовательские лицензии отдельно на каждом клиентском ПК.
Читайте также: