Вот вообще не проблема сохранить нужные настройки в Ini.
Если единственным вариантом видится только БЛОБ, то ИМХО что-то не то в консерватории.


Параметр CDS.Width - это список колонок в клиентском CDS и их ширина. Ширина со знаком минус - коронка скрыта. Пользователь может управлять видимостью колонок, скрывая ненужные.

Что-то не уловил связи между exe в БД и настройками программы.
У меня в БД не только exe, но и печатные формы, и файлы шаблонов прайсов, и собственно данные лежат :)



У меня рядом с программой лежит 2 ini.
Одна - со стокой коннекта к БД, и этот файл правится руками, когда надо.
Второй ini пишет и читает само приложение, сохраняя туда локальные настройки которые нет смысла хранить в БД.



Я не вижу в чем тут затратность.
В ini у меня на каждую форму по секции, далее параметр=значение. Читаю/пишу.
А где эта ini хранится - как-бы не суть. Но раз она имеет смысл только к рядом лежащему exe то почему бы не лежать рядом?
А так, можно этот ini хранить не в виде файла а в виде блоба в БД, ну ровно ничего от этого не меняется. Кроме головняка как различить какой из ini нужно из базы выковыривать.

Мое приложение однопоточное. Если нужна какая-то параллельная работа - то просто запускается второй экземпляр. Если нужно для одного экземпляра иметь одни настройки а для второго - другие - тупо копируем папку с приложением, что бы у них были разные ini-файлы - и всё.

Какая-то странная поделка. Чуть улучшает ситуацию для частного случая, но даже с ним как-то не очень. Но привносит свои ограничения. Мне например непонятно почему нужно себя ограничивать неупотреблением символа-разделителя между типа NAME и остальными параметрами. Разделитель там ' --'. А что если такая последовательность встречается в NAME?

Единственное что можно рассматривать как некоторый плюс DDV перед CSV - именованные поля, зная ключ поля можно выковыривать его произвольно из строки. Но однако, зная ключ (индекс поля) точно так же он выковыривается и из CSV.
Если же большой список параметров каждый из которых довольно редко встречается, то это тот самый ini и есть.



То что типа можно сортировать.. тоже непонятнько. Разница между DDV и CSV в показанных примерах только в том что в CSV поля могут быть окавычены и нет, это сбивает сортировку, но зато дает отсутствие проблемы с разделителем полей.
Сортировка прямо по файлу будет все равно корявая, длина поля для сортировки не фиксирована, да и зачем это надо, сам файл сортировать? Все равно это все загружается в некую структуру и там уже и сортируется по нормальному.

Кроме того, эта поделка решает вопрос как разобрать одну строку/секцию. А как найти нужную в файле? Ini этот вопрос решает, а тут остается за кадром. И в чем смысл?
Единственное где хоть как-то это может иметь смысл, я вижу в случае если типов полей тыща, но в конкретной записи штук 5. CSV в таком варианте будет состоять из большого количества разделителей полей.

Вспомнил, у меня же есть в базе таблица для хранения настроек :)



Планировалось засунуть настройки туда, но что-то не зашло.
Там сейчас только общие настройки, для всех, типа путь к папке с картинками и префикс URL до картинок на сайте.

Тот самый случай когда yaml начинает иметь смысл и незачем изобретать недовелосипеды :)

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