Интересно, есть ли альтернативный способ создания баз данных компонентов (Parts) в Part Editor'e? Для резисторов или конденсаторов приходится забивать огромное количество значений (для каждого значения номинала)... Неужели нельзя автоматизировать этот процесс?

В любом случае string самое универсальное. В любой системе обработки БД (напр. электронных таблицах) можно интерпретировать записанное строковое значение любым образом, при этом наиточнейше храня номинал детали со всем необходимым, включая символы, а не только цифры, без ограничений на точность при хранении числом ограниченной разрядности. А поиск... Искать можно и после преобразования из строки, которая в БД, в нужный формат, и после выборки по типу детали (резистор там, кондер, и т.п.)

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

Это укор ментору только в том случае, если он не поддерживает тип string в этом поле. А вообще - руководство к действию. Не надо путать разные по природе вещи - для языков программирования важен компромис по скорости обработки и занимаемому объему, а тут - эти критерии не работают. Тут важна универсальность. Не на столько велик объем этих БД, чтобы не конвертировать строки в числа в процессе обработки (сортировки, поиска и т.п.). Да и можно по ходу по мере добавления новых записей разгребать строковый полноценный value в отдельные новые (возможно скрытые) поля с числовым значением номинала, разбросом, и т.п. для ускоренной сортировки-поиска-обработки, опять же сторонними от ментора средствами работы с БД. Правда для ведения такой БД понадобится специально обученный специалист... Но я думаю, что там, где такая БД нужна в принципе, это оправдано.

Таким образом мы признаем, что в менторе реализация не очень-то правильная.
Может, все-таки кто-нибудь подобрал форматы так, чтобы не глючило? Ну никак не хочется ставить string и отказываться от automatic magnitude...

а что, sql server не поддерживает передачу double float из базы? так это может проблема его настройки или в начальной базе поле value просто float (не double)

Я согласен что string - наиболее универсальный вариант, сам его использую.
А вообще есть дикая идея написать замену DxDB с использованием automation в EE2007, с нормальной реализацией взаимодействия с базами данных. Ибо DxDB не позволяет сделать библиотеки настолько гибкими и универсальными как мне требуется. Но пока это только идея

Проверка не проходит. В схеме атрибут такой же, как в БД, но почему-то выделяется красным. Весь компонент, соответственно, тоже.


А что за гибкость нужна, если не секрет? В смысле, чем не устраивает?

Я считаю, что библиотека должна быть как можно более универсальной и наименее избыточной (данные не должны дублироваться). Из этого следует, что глобальная библиотека (от логистики до сборки и поддержки) должна остоять из нескольких уровней. Для САПР печатных плат по сути нужны 4 составляющие: symbol, landpattern, pinmapping (symbol to landpatterm) и некоторые атрибуты для отображения на схеме. Для различных симуляций нужна ссылка на модели, для логистики нужна ссылка на список взаимозаменяемых комопнентов. Причем все эти параметры могут зависеть от проекта: один и тот же компонент может требовать разных посадочных мест для разных плат, или для одного устройства значение ТКС резисторов 0603 значение имеет, а для другого нет, но символы, посадочные места и маппинг резистора в обоих случаях идентичен.
Все это и приводит к идее создания generic library (без привязки к ментору или кому-либо еще) и интерфейсов в различным САПР итп.

Это все верно и правильно, но dxdb чем Вам не угодил? Он же как раз только для схем.
Настраиваете себе библиотеки с паттернами, символами и параметрами для моделирования и занимаетесь проектированием. А параллельно остальной народ, пользуясь той же базой, делает закупки, бумажки и т.п.

Да не то чтобы он не угодил, просто если дойдут руки до реализации этой идеи, то делать надо правильно, а не прикручивать свою систему к DxDB, попутно тратя время на обход их косяков.

Ну, не знаю... Мы вот, хоть и свою систему пишем, но и про DxDB не забываем.
А вообще, если деньги есть, обратите внимание на менторовский DMS, там как раз все что надо. Даже в кейденсовский концепт можно компоненты из базы вставлять. И связи, и уровни, все есть. Жаль, самого его нет.

Знаю я DMS, туда лучше вообще не соваться - засосет )
Тут основная проблема в том, что при использовании DMS пользователь должен подстраиваться под ментор, а должно быть наоборот.