Пытаюсь подключить существующую MySQL базу данных, которая ранее создавалась под OrCad.
В результате дохожу до следующего окошка

Понятно, что здесь как-то надо переопределить поля. Но как?
По ссылке на wiki ни чего не понятно.
Может быть кому-то уже приходилось подключать подобную БД?

Похоже немного поторопился с вопросом. Всё нормально подключилось! Чтобы увидеть таблицу, нужно пыло нажать на кнопочку Table Browser!
Однако думаю эта тема всё равно актуальна, т.к. лично у мен\ подключение подходило не совсем гладко и ещё не ясно как оно пойдёт дальше!

К сожалению, пока полученную таблицу использовать не получается
Возможно в ней нужно каким-то образом прописать пути к существующим библиотекам символов и футпринтов?

При попытке сохранения проекта

Есть 2 пути. Или полностью указывать в одном из параметров путь к библиотеке
Или прописывать в настройках, директории, где лежат библиотеке.

Прописал в настройках

У меня прописаны и пути к библиотекам (относительно к dblib) и используемые УГО, и футпринт. Все работает.

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

TOREX, будте так любезны, опишите пожалуйста, как Вы прописывали-подключали, что после этого всё заработало. А то я уже в конец запутался

Дык он у Вас даже УГО не видит, должно быть как-то так:

Нажмите для просмотра прикрепленного файла

После, опять же, хаотических тырканий-мырканий появились футпринты. Подозреваю, что после манипуляций в области Field Settings. В окошке Database field поставил PCB_Footprint (такое поле есть в БД), а в окошке Part parameter поставил Footprint (выбрал из предложенного). Однако с символами это не помогло. Для БД название символа указывается в поле Schematic Part. Перебрал все варианты из Part parameter, всё чщетно. Может быть где-то эти параметры расписаны?

Library Ref-- это имя компонента\
Footprint Ref это имя посадочного места.

Все забронированные имена и их назначение находятся легко по F1, и там поиском выше озвученных параметро

Убедительная просьба к знатокам. Подскажите, пожалуйста, каким способом подключить AD к базе MySQL? Пока всЁ выглядит очень нетривиально. Складывается ощущение, что весь потенциал цивилизации направлен на усложнение всего и вся.
P.S. Поставлены сервер и ODBC драйвер. Тестовая база создана. Соединение с ней происходит нормально. Пока вроде всЁ упирается с создание строки подключения.

Так как специалистов не нашлось, пришлось всЁ разгребать самому (для пары тупиков призывался программист). Итог исследований в документе. Если будут замечания, пожелания и критика просьба отписать. При прочтении учитывайте то, что я совершенно не специалист по СУБД.
В дополнение хотелось бы от Сабунина Алексея получить ответ на простой вопрос: будет ли в дальнейшем поддерживаться подключение библиотек на основе БД сторонних СУБД (не Vault) и каковы перспективы развития этой поддержки?

Посмотрел мельком описание, очень подробное - наверняка пригодится последователям! Правда к подключению БД в AD относятся только последние 3 пункта, и на мой взгляд это самая простая часть.
Адресованный ко мне вопрос не очень понятен, разве сейчас нет поддержки сторонних СУБД?

Если посмотреть на тренд развития AD, то большое значение сейчас имеет Vault. Соответственно не ликвидируют ли поддержку сторонних СУБД после полноценного развертывания Vault? Ну а вторая часть вопроса была о нововведениях в области поддержки сторонних СУБД (если она останется).

Не думаю. Пока пользователей Vault на 2 порядка меньше, чем базы. Спите спокойно лет 10. Это включая развитие поддержки СУБД. И после того она будет если не развиваться, то поддерживаться однозначно.
так далеко не заглядываю. Но прогнозы давать можно

Работа с внешними СУБД очень востребована и ни куда не денется, это точно. Насчет второй части, было бы интересно чего именно не хватает. Если недостающие вещи уже реализованы в волте, то вряд ли они будут сделаны вне волта...

1. Необходимо лечить косяк открытия панели "Libraries" при наличии в ней библиотек на основе БД;
2. Реализовать поддержку относительного пути к PDF файлам в полях "ComponentLink...";
3. Реализовать поддержку длинных динамических полей - для СУБД MySQL поля типа "Text" (до 64 kB) не отображаются, или жестко указать имеющееся ограничение длины поля.
Ну и пара "проблем" не связанных с БД (лень писать в соответствующую ветку):
1. Поддержка настройки (параметра) "=Type" в поле "Comment" компонента библиотеки УГО.
2. Поддержка настроек (параметров) с пробелом в поле "Comment" компонента библиотеки УГО (например, "=Mydata Value" не передаЁтся в редактор плат, а передача "=MydataValue" уже проходит без проблем).

Это глюк оказывается, а я с бубном танцевал пытаясь разные имена полей присвоить

Пробую подключить базы данных Mysql к алтиуму через ODBC. Пробовал по мануалу Murzik_6011, пробовал через последнюю версию БД, одна и таже проблема - жуткие тормоза при инициализации либы в алтиуме и такие же тормоза (алтиум просто подвисает) при попытке выбрать и установить элемент в схематике. Та же самая база, подключенная через access просто летает.
win7 x64. 8GB ОЗУ core i5 4460, Mysql 5.6.40/Mysql 8.0.11 (пробовал разные БД) Altium 17.1.9 и Altium 18.1.6. По монитору ресурсов, при подвисании алтиума, ни процессор, ни hdd, ни сеть практически не используются, база находится на localhost.
Собственно переход был из за новой версии алтиума, для подключения к БД access необходим х64 драйвер, соответственно необходим х64 офис.
Кто нибудь сталкивался с подобной проблеммой и как её решали?

Рад, что кому то мануал пригодился и даже заработал.
На счЁт тормозов. У меня на машине развЁрнуты два варианта подключения к сетевым БД: на этой же машине к серверу MySQL и к внешнему серверу MS SQL. Поведение примерно одинаковое и не зависит от сервера и почти не зависит от производительности машины (на самом деле у меня две машины - одна слабенькая, другая - "производительная", но ситуация и там и там одинаковая). В панели "Libraries" библиотека открывается ощутимо долго (задержка несколько секунд) только при первом обращении, последующие выполняются почти мгновенно, слегка притормаживает листинг компонентов в списке. Однако, при доступе к библиотеке из окна замены компонента ("Choose...") тормоза такие же как при первом обращении к библиотеке. Судя по всему при втором и следующих обращениях в библиотеке через панель "Libraries" AD использует кэш, а при обращении для замены компонента - читает еЁ снова. ВсЁ описанное выше относится к AD до 18 версии, а главное - шЁл разговор о библиотеке с 46 тыс. компонентов (при меньшем количестве компонентов тормоза пропорционально уменьшаются). Сейчас в проекте библиотека на 220 тыс. элементов - посмотрю на тормоза.

Тестировалось на библиотеке, состоящей из двух частей:
8 элементов, и примерно 2000 элементов.
В обоих случаях тормоза при выборе элемента из библиотеки были постоянно. Что в момент первого выбора, что в последующие алтиум тупо зависал секунд на 20-30. Работать с такими тормозами просто не реально.

Ну вот вчера и произошло то событие, которое, по крайней мере я, очень ожидал...
Попытка подключиться к библиотеке на основе БД с 202 тыс. компонентов потерпела фиаско.
Теперь подробнее.
Была создана БД на 202 тыс. резисторов на MySQL-серваке (локально; утилита работы с БД отображает содержимое таблицы без проблем). С помощью DBLib она была подключена к AD: AD "приконнектился" к ней и смог прочитать структуру записи, но не смог отобразить содержимое таблицы - "ушЁл в себя", но вернулся без результата; "инсталляция" этого DBLib прошла успешно; однако попытка отобразить список резисторов в панели Libraries после 4,5 минут (ожидания) закончилась парадоксальным окном, в котором значиться, что невозможно выполнить запрос, но доступ открыт.
Вот такие кренделя. Похоже AD более 53 тыс. компонентов в БД не может переварить (может и больше, но это самая большая из имеющихся БД).
Далее сделал запрос к нашим админам - будут пробовать развернуть эту БД на корпоративном (внешнем) MS SQL-серваке, вот тогда и подведЁм итоги.
P.S. AD 17.1.9 на 64-битной Win7, версии MySQL - соответствуют описанным в мануале.

Долго пришлось ждать админа из отпуска...
Но...
Это всЁ таки случилось! После двух дней битвы с MS SQL сервером в нЁм была благополучно создана (а главное - импортирована из Excell) БД на 202 тыс. резисторов. СУБД стоит на отдельном сервере в локальной сети.
Был создан файлик подключения к ней DBLib и успешно инсталлирован в AD.
И вот тут барабанная дробь...
Попытка подключиться AD к этой БД прошла на ура. Все 202 тыс. резисторов были отображены в панели Libraries. Мне даже удалось пару штук поставить на схему...
Но есть одно маленькое "но" (хотя на самом деле оно не такое уж и маленькое)!
Время подключения к БД составило 45 sec, а время выбора второго резистора - целых 2 минуты)))
Так что наша "лодка" разбилась о камни бытия - скорости (производительности) не хватает.
Далее эта БД будет разбита на несколько БД.
Итого: AD может "грокнуть" 202 тыс. компонентов из сетевой БД; работать нормально можно только с БД, в которой число записей не превышает 50-60 тыс. компонентов (может быть это число равно 65535?); связка AD + MySQL сервер более 50-60 тыс. компонентов "переварить" не может.
P.S. Версия AD - 17.1.9, версия MySQL сервера - в мануале.