Они совместимы на очень "базовом", примитивном уровне. То есть на запросах вроде приведенных вами. Вообще, вы идете по печально известному пути написания независимых от СУБД приложений. Путь этот достижим только при полном отказе от сколько-нибудь сложных запросов, от триггеров и ХП, от встроенных в СУБД механизмов репликации и т.д. (то есть грубо говоря от всего того, что составляет мощь СУБД), либо за счет встраивания нескольких аналогов одного и того же функционала для N разных предусмотренных СУБД (то есть фактически стоимость разработки умножаем на N или около того).

Успехов.

Victor MetelitsaЭто некорректно. Скажем так, это просто упрощенное изложение.
Victor MetelitsaТриггеры, репликация и ХП здесь совершенно не причём. GUI-программа типа приведённой выше о триггерах и репликации просто не знает, да и вызов SP имеет похожий синтаксис. Это почти так. Однако сколько-нибудь сложная ИС все эти прелести обязательно использует. А если ИС без них, то значит она весьма простая, что и требовалось доказать.
Victor MetelitsaЯ в разработке пользуюсь Object-Relation framework'ом под названием GLORP, а раньше использовал TOPLink/S, они позволяют делать многие (хотя, к сожалению, и не все) вещи независимыми от СУБД. Соль в том, что программа, в том числе и запросы, даже очень сложные, пишутся на Smalltalk'е, а GLORP и TOPLink/S их транслируют на SQL с учётом особенностей сервера.А вот тут позвольте не поверить. Я не первый год пишу на SQL и знаю, что для сложных запросов нюансы конкретной СУБД жизненно важны. Видимо, мы по разному с вами понимем "сложность" запросов. Я уверен, что эта ваша (весьма странная) связка приемлемо сработает только на примитивнейших по моим меркам запросах, а на сложных даст просто ужасающее по производительности решение. Впрочем, если оно вас удовлетворяет, рад за вас. Но в целом предложенный подход IMHO имеет очень узкую нишу, хотя бы потому, что все задачи нужно решать на наиболее приспособленном для этого инструменте. А для задач работы с конкретной СУБД наиболее приспособлен собственный язык этой СУБД, то есть обычно конкретный диалект SQL.

1024какие-то пораженьческие настроения.Да можно, можно сделать-то. Но чем сложнее система и кучерявее запросы (особенно для сложных отчетов), тем трудозатраты будут выше. Тут никаким хранением "настроек" не поможешь. Ведь сложный запрос есть не просто один большой SELECT, а по сути целый скрипт с переменными (в т.ч. таблицами-переменными), циклами, курсорами и т.д.