После обновления по svn, обновляется Elements.sql, и надо обновлять Elements.db с помощью sql_to_db.bat, а она обновляться не хочет, если есть нестандартные компоненты в палитре(или еще по какой причине ), так вот с помощью hiUpdater можно обойти эту проблему. Только для пакета Windows(Delphi).
Программа имеет две функции, для их работы необходима папка для файлов-нестандартных-компонентов(тех, которых нет на svn), лучше всего помещать компоненты для операций в отдельную папку, т.к ведется поиск файлов с маской .ini и может нечаянно попасть лишний ini в список.
Первая функция - установить компоненты в HiAsm, генерируется файл install.his для компонентов из списка, вторая - удалить компоненты из HiAsm, генерируется файл uninstall.his для компонентов из списка.
Вот программа: code_13997.txt

"с помощью sql_to_db.bat, а она обновляться не хочет,"
библиотека sqllite там лежит? ;)

Ага, иначе бы я и не пробовал, я же сначала "заглянул" в батник,понял что нужен файл sqlite.exe, а потом запускал
------------ Дoбавленo в 11.11:
Ну по крайней мере у меня работает если нету файла Elements.db
------------ Дoбавленo в 11.14:
Он(sql_to_db.bat) мне пишет, что Primary Key must be uniqe, что-то вроде того

Assasin, а так ничего не надо и про Primary Key must be uniqe не пишет. И старый Elements.db не перезаписывает, а только добавляет новые компоненты. И, наверное, не

Assasin, "Primary Key must be uniqe" есть результат того, что батник не удаляет старый Elements.db перед созданием нового - см sql_to_db в моих пакетах (wxMsw, Python).

По программе: (пмсм) лучше реализовать несколько другой подход: пробегался бы по папке conf и искал бы элементы, которых нет в Elements.db.

а потом бегать по Elements.sql и искать отсутствующий, что бы узнать куда его положить ?
Выше в sql_db.sha реализовано проще.
а мне и не нужно удалять старый - у меня там куча нестандартных и эксперементальных компонент.

Tad, а зачем по sql? Поясняю свою мысль:

Шаг 1. Из sql пересоздаём db, открываем созданную базу
Шаг 2. Бежим по директории conf, ищем ini-файлы
Шаг 2a. Для каждого ini смотрим (SELECT COUNT(*) FROM Elements), есть ли такой элемент, если нет - добавляем "не отходя от кассы".
Шаг 3. Закрываем базу

Так понятнее?

Или, если есть проблема с распихиванием по Tab-ам:
Шаг 0. Копируем имеющуюся базу в (скажем) Temp.db, открываем её
Шаг 1. Из sql пересоздаём db, открываем созданную базу
Шаг 2. Бежим по директории conf, ищем ini-файлы
Шаг 2a. Для каждого ini смотрим (SELECT COUNT(*) FROM Elements), есть ли такой элемент, если нет - запрашиваем Temp.db на предмет "куда его запихать" (Tab, Pos) и пихаем.
Шаг 3. Закрываем базы

iarspider, НЕ СОГЛАСЕН.
1. Выбираем из Elements.sql все готовые строки с INSERT INTO и меняю значение id на null
2. Проверяю наличие компонента в таблице и если нет то выполняю готовое ! INSERT INTO туда, куда хотел автор компонента, не отходя от кассы.

и не ищу никаких ini.

Tad, продолжаем разговор.

В стандартном пакете со строками я давно уже не работал, но когда активно работал (как раз когда на SVN стали sql класть, а не db) - замучался писать логику для парсинга строки запроса.
Не знаю, может теперь это стало проще.

Навскидку могу придумать только один случай, когда твой алгоритм будет корректнее: когда "потусторонние" (с) компоненты были установлены в отдельную подвкладку (группу). При моём методе псевдоэдемент-разделитель потеряется, при твоём - нет. Но в твоём методе надо очень аккуратно запросы составлять (с явным ORDER BY).

Давай.
Просто я не люблю лишних движений.
"потусторонние" установлены в отдельную вкладку (MyComp)
Про ORDER BY не понял. Зачем он нужен?
За все время пользования выложенной програмкой - ни разу не было сбоев и ни разу не приходилось ремонтировать Elements.db.
Сейчас бы реализовал по другому, но алгоритм оставил бы тот же.

Tad, да в принципе ясно всё, после последних уточнений