Database libraries, с чем это едят Опции

[тау]

Особо радует добавление нового компонента Про Ввод через Access можно забыть

можно то можно, но ввод сделан не по-людски , скопировать строку целиком нельзя и пару циферек поменять. В таблице Access или Экселе было проще размножать похожие элементы (резисторы) , заменив номинал и партнамбер в скопированной строке . Хотя эта возможность и осталась и без использования новшеств в AD.

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

вот тут проверил - можно оказывается кое что сделать и в этом направлении.
Заводим базу DBLib, указывающую на MDB . В MDB таблицы не размещаем, а только запросы . Запросы альтиум подхватывает как будто это таблицы. В запросах пишем через Select все что хотим , а в качестве полей и таблиц запросов указываем таблицы из связанной базы данный (другой MDB файл, ссылка на таблицы которой лежат в первом MDB) , где структура таблиц может быть произвольной, в том числе и заточенной под другие нужды, например склад, производство, закупки. Удачно то , что ссылки на таблицы "другой" базы Альтиум не показывает в своих окнах а только запросы. Можно даже разделение прав пользователей прикрутить, а Альтиуму разрешать только чтение. Когда уже есть некая производсвенная база со своей оболочкой и структурой данных, то тут это можно и использовать. В той же первоначально имеющейся базе конструктор и новые элементы заводит, с привязкой к символам и футпринтам.

[Владимир]

можно то можно, но ввод сделан не по-людски , скопировать строку целиком нельзя и пару циферек поменять. В таблице Access или Экселе было проще размножать похожие элементы (резисторы) , заменив номинал и партнамбер в скопированной строке . Хотя эта возможность и осталась и без использования новшеств в AD.


вот тут проверил - можно оказывается кое что сделать и в этом направлении.
Заводим базу DBLib, указывающую на MDB . В MDB таблицы не размещаем, а только запросы . Запросы альтиум подхватывает как будто это таблицы. В запросах пишем через Select все что хотим , а в качестве полей и таблиц запросов указываем таблицы из связанной базы данный (другой MDB файл, ссылка на таблицы которой лежат в первом MDB) , где структура таблиц может быть произвольной, в том числе и заточенной под другие нужды, например склад, производство, закупки. Удачно то , что ссылки на таблицы "другой" базы Альтиум не показывает в своих окнах а только запросы. Можно даже разделение прав пользователей прикрутить, а Альтиуму разрешать только чтение. Когда уже есть некая производсвенная база со своей оболочкой и структурой данных, то тут это можно и использовать. В той же первоначально имеющейся базе конструктор и новые элементы заводит, с привязкой к символам и футпринтам.

Ну парой циферек не обходится. Тем паче всегда на этой паре одну забываешь изменить, и начинаешь потом расхлебывать.
зато есть Edit Suplier Link Который позволяет вообще нужное задать самому не занимаясь вводом
А насчет запросов, мысль интересная. Будет время, может попробую,
Сразу об этом даже не думал. Сэнк за наводку

[uriy]

Я так и не начал работать с БД. Жду статью Владимира. Тем временем пока балуюсь по немножку с БД. Открыл ту что идет в комплекте с AD для примера Altium Designer Summer 09\Examples\Cis. В VishayCapacitor.DBLib отредактировал пару полей, намеренно испортил данные как на скриншоте. Но несмотря на это компиляция DBLib проходит без каких либо варнингов. А в схему такой компонент естественно не вставляется потому-что AD не знает откуда брать УГО - я же его попортил. Мне кажется было бы логично выявлять подобные ошибки при компиляции DBLib разве нет?

[тау]

..... Мне кажется было бы логично выявлять подобные ошибки при компиляции DBLib разве нет?

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

[Владимир]

Я так и не начал работать с БД. Жду статью Владимира. Тем временем пока балуюсь по немножку с БД. Открыл ту что идет в комплекте с AD для примера Altium Designer Summer 09\Examples\Cis. В VishayCapacitor.DBLib отредактировал пару полей, намеренно испортил данные как на скриншоте. Но несмотря на это компиляция DBLib проходит без каких либо варнингов. А в схему такой компонент естественно не вставляется потому-что AD не знает откуда брать УГО - я же его попортил. Мне кажется было бы логично выявлять подобные ошибки при компиляции DBLib разве нет?

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

[тау]

Мне понадобилось привязать Альтиум к некоторой базе данных ( производственная ) , содержащей спецификации сборочных единиц , партнамберы элементов, информацию по закупкам и складу. Главная идея - партнамберы должны храниться в единственной базе данных и не дублироваться в разных базах, для исключения ошибок. Общая схема такой базы представлена на 1-м рисунке.


Чтобы прицепить эту базу, создаю файл EX5.MDB с запросами и ссылками на проиводственную, например такой (рис.2)

В Альтиуме создаю файл библиотеки EX5.DbLib и указываю на EX5.MDB (рис.3)
В "Field Settings" настройках для каждого запроса указываю что связь идет через PartNumb . Это надо сделать для каждого запроса , появившегося в колонке Table (слева вверху). Сохраняю EX5.DbLib.

Инсталлирую EX5.DbLib в библиотеках Альтиума (4-й рисунок). Вроде работает


Основной смысл использования такого подхода - это возможность лёгкой закачки получаемого из Альтиума ВОМ-а в производственную спецификацию (в производственной базе) без конфликта по партнамберам. По безбумажной технологии.


PS. еще пара мыслей:
Базы после создания и значительных модификаций надо сжимать , иначе удаленные таблицы , (если они там были) ,
начнут призраками появляться в Альтиуме под причудливыми именами "~TMPxxxxxx". Сжатие стандартно в ACCESS через "Сервис\Служебные программы\"Сжать и восстановить базу данных..."

Бывают производственные базы, защищенные паролями для пользователей. Альтиум же заходит по умолчанию с логином Admin и без пароля. Чтобы Альтиум смог пробиться через запросы к запароленной базе, нужно чтобы действующий администратор назначил юзеру с логином Admin права на чтение тех таблиц из производственной базы, которые фигурируют в запросах альтиумовского MDB файла.
В рассмотренном примере права на чтение Admin-у заложены по таблицам CompCls, CompV, FtPRT. Само собой редактировать через Альтиум Summer такую базу уже не получится , а оно и не надо , имхо, ибо баловство.

Сообщение отредактировал тау - Dec 20 2009, 14:25

Эскизы прикрепленных изображений

 

[uriy]

Так вроде журнал должен уже появиться

Появился, но до нас еще не дошел.

Вы могли подпортить запись и дугим образом, например так, чтобы исправленное УГО своим наименованием указывало на другое УГО, имеющееся в библиотеке. А откуда Альтиум должен знать что указанная ссылка на УГО технически и по сути верная?

Теперь внимательней читаем то что я написал и смотрим куда на картинке указывают красные стрелки. Capacitor - non polarized исправлено на Capacitor - non polarize (без буквы d в конце) и Discretes.SchLib исправлено на Discretes.SchLi изменено расширение. Такого компонента и бибилотеки с таким расширением нет, если бы они были то было бы неверным другое мое утверждение - "А в схему такой компонент естественно не вставляется потому-что AD не знает откуда брать УГО - я же его попортил."

[Владимир]

Появился, но до нас еще не дошел.

До меня тоже. Но где-то же уже есть

[тау]

uriy, В DBLib все корректно.
"non polarize" это значение поля в файле VishayCapacitor.mdb, который Вы не компилировали и в котором по задумке не заложен контроль целостности. Ничего удивительного.

[Владимир]

Мне кажется было бы логично выявлять подобные ошибки при компиляции DBLib разве нет?

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

[uriy]

Тогда что происходит при нажатии Project->Compile Document x.DbLib?
Я думал должна пройти проверка валидности пути к бибилиотекам Library Path и Footprint Path затем проверка наличия в этих библиотеках Library Ref (УГО) и Footprint Ref (футпринта).

[Владимир]

Тогда что происходит при нажатии Project->Compile Document x.DbLib?
Я думал должна пройти проверка валидности пути к бибилиотекам Library Path и Footprint Path затем проверка наличия в этих библиотеках Library Ref (УГО) и Footprint Ref (футпринта).

Только то, про что тут красиво ругают-- красивая фича, нажал, и ничего. Хоть бы сообщение какое, аль привет Оно не проверяет даже а есть ли такой Document x.DbLib

[ellboy]

Как всегда, после выхода у Потапова.
Пока она в редакторской правке.

Доступна ли уже электронная версия статьи?

[Владимир]

Доступна ли уже электронная версия статьи?

Номера не видел, но наскоко понимаю еще в прошлом году должен был быть.
Там только начало

[Марик]

Подскажите, как лучше организовать совместную работу с dblib?
У нас есть сервер, на котором хранятся файлы базы данных, библиотеки УГО и посадочных мест, даташиты... В общем, все, что можно отнести к производству. Смущает следующее: при одновременном редактировании файла библиотеки УГО или посадочных мест альтиум выдает сообщение, что файл был изменен и спрашивает стоит ли его перезагружать. Однако, если я правильно понял что произошло , при ответе "да", внесенные собственно в этот файл изменения не сохраняются и приходится создавать заново, а при ответе "нет" последующее сохранение может "затереть" изменения, сделанные другим пользователем. Подскажите как лучше всего нам организоваться и есть ли у альтиума какие-то возможности, чтобы помочь в этом?

Сообщение отредактировал Марик - Feb 28 2010, 17:07