Lotsia PLM: Форум по семейству систем PLM/PDM/TDM/ERP/Workflow

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

Имеется атрибут, значение которого можно выбирать только из списка. Например стадии проектирования "П", "Р" и т. д.. Если одно из значений атрибута реализовано хотя бы в одном объекте то удалить его невозможно.

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

Поиск объектов со злосчастным значением атрибута выдает пустой список, однако Lotsia упорно заявляет о невозможности удаления из-за наличия ссылок в базе данных!

Что с этим можно сделать

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

Спасибо за помощь!

Печально однако, что Lotsia накладывает достаточно жесткие ограничения на процесс проектирования. Эти вещи:

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

делают невозможным сохранение базы данных в чистоте от подобного "мусора" в условиях "горячей" разработки структуры . Если это сделано для обеспечения защиты целостности БД, то не оправдывает, на мой взгляд этой цели: администратор - человек ответственный. В крайних случаях можно использовать резервный backup БД.

Для кого пишу, сам не знаю

Юрицын Андрей писал(а): Печально однако, что Lotsia накладывает достаточно жесткие ограничения на процесс проектирования. Эти вещи:

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

делают невозможным сохранение базы данных в чистоте от подобного "мусора" в условиях "горячей" разработки структуры . Если это сделано для обеспечения защиты целостности БД, то не оправдывает, на мой взгляд этой цели: администратор - человек ответственный. В крайних случаях можно использовать резервный backup БД.

Все очень просто объясняется: эти ограничения связаны, в первую очередь, с поддержкой работы в многопользовательском режиме, особенно, когда у нас несколько баз данных.
Представьте, что Вы внесли новое значение (параметры детали), оно было передано в другое подразделение, там по нему что-то сделали (сделали матрицу), а потом Вы удалили информацию в исходной базе. Как "найти концы" в случае брака?
Не говоря уже о случаях злостного вредительства (краж и т.п.).
Да и ISO 9000 требует полной прослеживаемости.
Так что удалять введенные и хотя бы один раз использованные данные нельзя. ИМХО, идеологически тут все правильно.
А неиспользуемые "лишние" данные всегда можно переименовать и использовать повторно; или сделать так, чтобы они не отображались.

Юрицын Андрей писал(а):Для кого пишу, сам не знаю

Для коллег? Для разработчиков? Или для всех нас. Как Вам больше нравится.

Еще один способ избавиться от мусора в базе - править саму базу . дело конечно опасное, как говориться, "на свой страх и риск", но - работает! Лоция сделала структуру базы и связи достоянием нужной общественности (хотя что то можно было понять и без этого, так даже интересней ), так что исправить что то - проблемы большой составить не должно. про этот конкретный случай деталей сказать не могу, помню, что то то было, тоже связанное с историей, все убрал в итоге . небольшое отступление от темы, но тем не менее про ту же базу: еще одно полезное применение - правильное наследование атрибутов. база организована так, что у каждого объекта есть СВОЙ атрибут, то есть если у объекта Проект есть атрибут Название проекта и у объекта Стадия есть атрибут Название проекта, то в базе есть две записи - атрибут у проекта и атрибут у стадии. но это в виде ссылок на значения этого атрибута. в итоге само по себе значение вида "название какого то огромного проекта" лежит в базе всего один раз. и если вдруг нужно исправить название у всех уже созданных объектов (а из уже может быть ого го сколько), то или делать подборку для всех них и там устанавливать атрибут, или найти это значение в базе и поправить его....

мысль не совсем в тему этой темы , но тем не менее... недавно при создании типа атрибута обратил внимание на поле Связь. там два значения - Объект и Проект... ЧТО ЭТО ТАКОЕ? у нас все атрибуты со связью Объект, может быть поэтому приходится "наследовать" атрибуты через БД (см. предыдущее сообщение от меня же) есть у кого нить опыт работы со связью атрибута Проект? поделитесь плиз! а то какое то чувство закралось.... может.... может у НАС ВСЕ СДЕЛАНО НЕПРАВИЛЬНО???? думаю, попробую рано или поздно этот тип связи, но может у кого то уже что то получилось?

Anderyt писал(а):мысль не совсем в тему этой темы , но тем не менее... недавно при создании типа атрибута обратил внимание на поле Связь. там два значения - Объект и Проект... ЧТО ЭТО ТАКОЕ? у нас все атрибуты со связью Объект, может быть поэтому приходится "наследовать" атрибуты через БД (см. предыдущее сообщение от меня же) есть у кого нить опыт работы со связью атрибута Проект? поделитесь плиз! а то какое то чувство закралось.... может.... может у НАС ВСЕ СДЕЛАНО НЕПРАВИЛЬНО???? думаю, попробую рано или поздно этот тип связи, но может у кого то уже что то получилось?

Бедные, как же вы без проектных-то атрибутов-то!
Без них ведь ни одну структуру не опишешь! В доке же про это хорошо прописано: Свойство, описывающее собственно объект - объектный атрибут, а свойство описывающее принадлежность объекта к другому объекту - проектный атрибут.
Например, имя у девушки - объектный атрибут, а вот фамилия - проектный. Пока с папой живет - одна фамилия, потом замуж выйдет -другая...

У нас сейчас все атрибуты объектные, их приходится наследовать при создании каждого объекта (а все объекты создаются действиями), так что структура более менее описана Пример с девушкой многое объясняет , но и порождает вопросы. Обычно девушка в каждый момент времени замужем за одним человеком, и "проектный атрибут" может быть только один. а как быть с объектом Парти ?он может быть сразу в нескольких местах одновременно, что будет с его проектным атрибутом? смотря как смотреть (смотря через какой проект)? и еще.. вот например атрибут Обозначение. у объекта на одном из верхних уровней он может выглядеть как "1234-УКПГ", на следующем уровне - "1234-УКПГ-1", и далее - "1234-УКПГ-1-АС". можно ли в таком случае из обозначения сделать проектный атрибут? тогда придется для каждого нового уровня задавать новое значение этого атрибута в соответствии с принятыми правилами... такое возможно?

Я последнее время немного отошел от администрирования Lotsia PDM Plus, но скажу одну вещь...

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

Мы, как мне кажется, нашли более гибкий способ. Свелось все к написанию процедуры в базе данных и маааленького аддона, который вызывается при попытке модификации атрибута!

Собственно сама процедура получает, как мне помнится, ID объекта и ID типа. Остально можно получить из базы данных.

Нашел процедуру в Sybase Central.
ALTER function LSDBO.XXX_GetMarkaValue(in @type_id numeric(18), in @obj_id numeric(18)) returns varchar(2000)

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

После чего, на базе полученного анализа формируется обозначение. Причем сами значения частей обозначения берутся из родителей.

Например: объект "Площадка" атрибут "Обозначение" значение "КЮ". Это самое КЮ и войдет в обозначение. И так с каждым предком.

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

Alxd писал(а):Свелось все к написанию процедуры в базе данных и маааленького аддона, который вызывается при попытке модификации атрибута!

а у самих предков как выглядит Обозначение? у той же площадки - просто "КЮ", или что то есть вначале?
и что именно скрывается под "попытка модификации атрибута"? например, если вдруг решили поменять номер объекта по генплану, а уже чуть ли не все чертежи подписаны, что делать? как у имеющихся чертежей поменяется атрибут Обозначение?

а у самих предков как выглядит Обозначение? у той же площадки - просто "КЮ", или что то есть вначале?

Каждый предок несет кусочек обозначения, за который он и отвечает. Ведь не секрет, что по обозначению читая его справа налево можно понять где находится объект.

и что именно скрывается под "попытка модификации атрибута"? например, если вдруг решили поменять номер объекта по генплану, а уже чуть ли не все чертежи подписаны, что делать? как у имеющихся чертежей поменяется атрибут Обозначение?

Читай в доке по написанию "плугов". Там есть инфа о том, что есть три типа вызываемых процедур внешнего модуля. Одна из них, как раз подходит для модификации значения атрибута.

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

До плугов мы не доросли еще . как и до процедур...
а у нас у каждого объекта есть ПОЛНОЕ обозначение... все равно один и тот же объект (из состава проекта конкретно) не может входить сразу в несколько родителей. копировать - да, но добавление связи мы не приветствуем, поэтому такой подход (с полным значением обозначения) не приносит особых проблем.
однако до недавнего времени смена обозначения родителя с последующим обновлением у всех нужных потомков представляла определенные трудности. но недавно сделал как раз действие, которое меняет часть обозначения на новую строчку. это действие запустить для подборки, в которой есть все потомки объекта, с которого началась заваруха, ввести один раз старую часть обозначения и новую часть обозначения и поехали! действие поменяет как надо...

Все ясно. Под "процедурой" я понимаю понятие Лоции "шаблон". Это так. На всякий случай пишу.

Твой подход не так прост. Скажу так, не соответствует

лучше день потерять, потом за пять минут долететь!

Мне так кажется

Alxd писал(а): Твой подход не так прост. Скажу так, не соответствует

лучше день потерять, потом за пять минут долететь!

Мне так кажется

нормальный подход!!! мультики надо правильные смотреть!!!
а прикинь, поторопишься, потом переделывать????

Этот мультик у меня на почетном месте в каталоге mp4!
А ведь страус в конечном счета так и не поел! Гриф запарился, а страус своей дорогой пошел...