Здравствуйте, Владик, Вы писали:

В>Ну и нафига мне на клиенте имя таблицы? И вообще, зачем на клиенте знать что-то о какой-то там базе данных?
Ну а нафига тебе на клиенте та строка, которую я привел? А она достаточно типична. Что, пользователю что-то имя констрейнта скажет?

В>Кстати, почему ты СУБД причисляешь к нижнему уровню? Это вполне себе полноценное звено системы, имеющее собственную логику.
Потому, что ниже нее уже ничего нету. Это на самом деле неважно. Просто клиент должен показывать что-то типа "Нельзя удалить Склад №2 потому, что на нем числятся товары", а не всякое шаманство. И неважно, откуда приезжает эта строка — из базы данных, из middle tier, или ее клиент формирует. Просто информация о косяке должна передаваться снизу вверх в том объеме, который необходим и достаточен для выполнения задачи.
Если блин очередной уровень выкидывает строку типа "FK Violation" — то все, труба. С этой строкой уже нельзя сделать ничего полезного. Информация потеряна. Тот вымышленный пример объекта, который мог бы вылетать из RDBMS заместо строки, можно превратить в съедобное сообщение. Потому, что в нем есть информация. Неважно, где бы происходила эта замена. В сторед процедуре (которая, собсно, является этаким уродливым выростом в сторону middle-tier на теле сервера данных — пожалуйста. Ежели сможете. Потому как не все сервера дают даже там доступ к информации об ошибке, предпочитая отдать на клиента ту самую ненавистную мне строку через голову DB-программера.

И кончается это тем, что разработчики приложений, которые уважают своего пользователя, вынуждены идти на унизительные упражнения типа парсинга текста ошибки в поисках имени таблицы (что приводит к необъяснимым сбоям при апгрейде RDBMC), предварительной проверки всех мыслимых условий (что является избыточным и просаживает перформанс), и так далее.
Не надо идти на поводу у лентяев из Inprise. Не надо считать следующий уровень интеллектуально ограниченным и скрывать от него информацию.