Вопрос к Dilma.
Развелось в Хиасме множество компанент для работы с БД. На MSSQL, я так понял, все уже забили, мало примеров использования, да и смысл его теряется с появлением SQLite, как более мощного конкурента.
На повестке дня вопрос о MySQL. Будет ли развиваться и поддерживаться subj, или уже пора переходить на доступ к оному через ODBC?

Alexeylp, а что тебя не устраивает в MySQL компонентах? Они работали, работают и будут работать

Chesh, не знаю, что не устраивает Alexeylp, а меня не устраивает (в MySQL) невозможность вывода "наружу" точного кода и текста ошибки MySQL (mysql_errno() и mysql_error()). Для себя я сделал кое-как (только errno, текст пока не знаю как правильно выводить), а вот как быть тем, кто не может сам себе сделать?

Меня как раз всё очень даже устраивает, просто мой мозг разъедает пароноидальная догадка: если количество однотипных компонент растёт, то со временем разработчик(Dilma, для тех кто не понял ) начинает терять интерес к некоторым из них.

И чего
Было замечено, что он не фиксит в них баги, буде такие обнаружены

Galkov, а зачем ждать, когда это будет замечено? Я вот например MSSQL не использую, чего и другим желаю, ибо смерть его предрешена, имхо.

Политика в области БД, на мой взгляд, в корне неправильная. Зачем делать массу однотипных компонент? Если, допустим, есть SQLQuery, то он должен быть один, а не на каждый тип баз данных. Ясно, что действия в каждом случае разные, но эти действия нужно перенести в компонент, который является базой данных. Например в случае с SQLite мы тянем связь к Handle базы данных, но эта связь должна возвращать не SQLite handle, а некий интерфейс, по аналогии с массивами и матрицами. У этого способа помимо очевидного преимущества - сокращение количества компонент, есть ещё и другое - чтобы перейти на другую базу данных достаточно заменить лишь один компонент (большинство всё равно использует только базовый синтакс SQL). Кроме того, можно иметь возможность выбирать соединение с базой (различных типов) в разрабатываемой программе.

iarspider, да, с ошибками ситуация не очень... 2 да 3. Если есть наработки по поводу ошибок поделись плиз.
tsdima, мысль то конечно недурна осталось только написать этот "мега" dbSQL и уговорить Dilma. Я уже с пол года уговариваю чуть доработать TArray... А вообще я за. По крайне мере с MySql и SQLite можно поучавствовать. Про MS не скажу не общался.
Можно обойтись и без интерфейса. Там то делов, к разным dll кам обратиться.

Прежде чем уговаривать Dilma хотелось бы обсудить концепцию интерфейса. Не всякий набор функций подойдёт для любой базы данных. Один из таких наборов - ODBC, но он уже устарел. Есть ещё ADO (или более низкого уровня - OLEDB), но там в основе COM-технология и в HiAsm она не очень-то вписывается. Например, если под тем самым Handle подразумевать ADODB.Connection - попробуй написать все объекты ADO (Connection,Recordset,Field,Command,Parameter и др.) для SQLite.

Абсолютно справедливо.
Причем, вопрос касается не только баз, а "объектов" вообще. И массивов в том числе

tsdima, А если попроще, скажем, как TArray по пути интерфейсов - то примерно вот что получиться:
В итоге получим примерно то, что хотели. Но переписать прийдется все компоненты связанные с SQL.

... не надо

З.Ы. У меня, можно сказать, Хиасм-юбилей. Год назад (27.10.05) оставил тут (вернее там где тогда было) первый свой пост. Помню, тогда тоже была оживлённая дискуссия по поводу объектов.

tsdima, предлагайте...