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

Сейчас насущный вопрос:
Сделать релятивную базу в Access по следующей схеме


1 Как сделать запрос, что бы сохранилась возможность задавать несколько корпусов для одного резистора?
Простой запрос не позволяет этого сделать

Я, конечно, дико извиняюсь... Но что означает слово "сохранилась"? Она уже была? И что означают слова "несколько корпусов для одного резистора"? Альтернативные посадочные места с разными размерами?

В CIS есть возможность добавлять новые записи в БД. При этом можно назначить на одну запись несколько корпусов и несколько УГО.

В CIS можно записать в ячейку несколько корпусов через запятую (запятую по-умолчанию).
Тогда в CIS, в данном поле, появляется выпадающий список с этими самыми корпусами.
Можно сделать запись в таблице Footprint уже с несколькими корпусами.
Я же хочу для каждого значения корпуса иметь одну запись в таблице Footprint, а в таблицу Resistor подставлять эти значения и подставлять столь необходимую запятую.
Внимание вопрос! Позволяет ли Access внутри запроса подставлять эту самую запятую.

Что-то тяжко мне сформулировать свою мысль.

У нас это решается с помощью программирования хранимыми процедурами. Буратино говорил, что в аксессе это все легко. Спросите у него. Впрямую этого не делает ни один сервер.

Oracle позволяет сделать такой финт прямо в запросе, с 11 версии (краем уха слышал).

В Access есть Модули и Скрипты, может с помощью них можно сделать, кто знает?

самое главное ЗАЧЕМ????
ведь каждому номиналу и корпусу соответствует определенный партнамбер производителя, вы работу схемотехнику облегчаете, а менеджеру по закупкам усложняете, нет?
мы сейчас стоим на том же распутье в организации базы данных, но нас сдерживает PDM система, в том что передать в PDM надо именно партнамбер компонента, ну и согласитесь, что потом ручками его туда вколачивать это адский геммор. если вы скажете, что удобство работы схемотехника превыше всего, то наш начальник производства не согласится и будет наверное прав "ваши там файлики и прочее - фигня, без нормально оформленной документации, по которой ваши идеи можно было бы БЕЗ ВАС воспроизвести. без документации это всего лишь файлы".
поэтому будем на каждый номинал, на каждый корпус и прочие параметры компонентов заводить отдельную строку в БД. да БД будет не маленькая, ну а что делать?
в конце концов в CIS довольно удобная система поиска.

Самый простой пример - электролитический выводной конденсатор. Может стоять, может лежать на одном боку, может лежать на другом боку. Будете три партнамбера делать? Вряд ли. Захочется под одной записью провести, а в данном случае это еще и правильно будет. Вот тут и понадобится alternative footprint. Можно еще вспомнить, где понадобится, но это пример наиболее очевидный.

Ну и на один корпус можно сделать несколько футпринтов: нормальный, уменьшенный, увеличенный.

Как в том анекдоте: "... на русском форуме вам объяснят, что вы му*ak, и занимаетесь не тем чем нужно".
Здесь мы не будем обсуждать надо это или нет. Есть вопрос, если у вас есть ответ, или дельное, обдуманное предложение - велкам, нет - читаем первое сообщение, там есть ссылка для холиваров.

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

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

Тем, кто создает новую базу, советую сразу же включать в нее справочники корпусов как отдельных сущностей и посадочных мест тоже как отдельных сущностей. Тогда и связи настраивать проще, и реальность это отражает лучше. И т.д., не буду утомлять.

Хм.. а это идея.
Надо сделать 3 таблицы:
1 Package (r_0805)
2 Footprint (r_0805, r_0805_s, r_0805_l)
3 Resistor

3-ая содержит ссылку на 1-ую, а 1-ая - на 2-ую. Гуд .
Получится ли при этом из CIS создать новый компонент с несколькими футпринтами...

Теперь возникает второй вопрос:
Надо ли создавать отдельные записи для корпуса резистора и конденсатора (r_0805 и с_0805)?

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

Мы немножко торопимся. От простого к сложному. Пока это все не укладывается в голове.

Зайдем с другой стороны:
Надо ли создавать отдельные записи для футпринта резистора и конденсатора (r_0805 и с_0805)?
Для Allegro Editor это ведь особо и не нужно.


Про стандарты.
Киньте кто-нибудь данные стандарты, или ссылку.
Еще где то проскакивало про соответствие номера пина и вывода, например для электролита, диода. Тоже хотелось почитать такой стандарт.

имхо, надо. Например, шелкография может быть разной, что полезно.
Кроме того, я для футпринтов использую за основу IPC7351, так там прямо прописано, что резисторы имеют префикс RES, а конденсаторы - CAP.
Считать IPC7351 основой или нет - дело Ваше, с точки зрения БД это фиолетово. Я советую иметь для каждого футпринта в базе несколько наименований и ссылок на стандарты, по которым они именуются.

Таки поделитесь IPC7351. Или он легко доступный?
Какие еще есть стандарты для наименований?

Для Вас - да. Сходите в закрома.
Раньше был, по-моему, IPC-782 (боюсь напутать цифры), в некоторых проектах, возможно, увидите еще такие футпринты. А до того, вроде бы, и не было ничего, кто во что горазд. Он потому и появился.