Мне кажется на уровне сервера не должно быть никаких неявных преобразований никаких пустых строк в никакой NULL. В конце концов если я написал <WHERE Field = ''>, то значит именно это я и написал и не надо за меня выдумывать всякие NULL. Если мне сильно захочется контролировать, чтобы в стринговых полях не было пустых строк, никто мне не мешает сделать домен <VARCHAR() CHECK (Len(@) > 0)> и выбирать его в качестве типа для строк или же где нужно делать BEFORE TRIGGER, который пустые строки явно преобразовывает в NULL.

авторЕщё в аксессе так же, как и в оракле Только в отличие от оракла поведение можно себе на голову изменить :

If you want Microsoft Access to store a zero-length string instead of a Null value when you leave a field blank, set both the AllowZeroLength and Required properties to Yes.

ну и соответственно продолжение банкета :

You can use the Format property to distinguish between the display of a Null value and a zero-length string. For example, the string "None" can be displayed when a zero-length string is entered.
Нуу, так как PowerBuilder дедушка Access, то естественно в нем то же самое. И я считаю это правильным - программист клиентской части на каждое поле вправе выставить флаги "IsEmptyToNull" (если пустое, то в NULL) и "Required" (обязательно к заполнению), таким образом вводя дополнительную проверку на ввод данных к контролю БД. Ну а для тех инструментов построения клиентских приложений, у которых такой возможности контроля преобразования пустых значений нет ... считаю это их личными проблемами, ни коим образом не влияющими на работу СУБД и уж тем более механизм интрепретации пустых строк и NULL.

softwarer ASCRUSЕсли мне сильно захочется контролировать, чтобы в стринговых полях не было пустых строк, никто мне не мешает сделать домен

И я считаю это правильным - программист клиентской части на каждое поле вправе выставить флаги "IsEmptyToNull" (если пустое, то в NULL) и "Required"
Само по себе - правильно. Но давайте представим приложение, допустим, тысяча форм, из них штук шестьсот - ввод данных. В каждой форме десять-двадцать полей. Итого - из десяти тысяч потенциальных "вправе" программист клиентской части несколько раз забыл, ошибся..

Повторюсь: как только я столкнулся с прямой необходимостью это предусматривать - я стал больше ценить оракловое решение.
По мне уж лучше CHECK для поля или домена. В принципе конечно может у меня привычка сложилась не доверять программистам клиентских приложений (в том числе и себе), но на БД у меня всегда поднят полный контроль на все мыслимые чихи не только пользователей, но и программистов/админов. С одной стороны это мне гарантирует целостность данных вне зависимости от того, кто, когда и как пытался их внести. С другой стороны такой контроль неплохо себя зарекомендовал как бесплатный автотестер кодерской части, который частенько тыкает программеров клиентской части носом в различные несоотвествия того, что есть и что/как они пытаются получить/изменить. Единственное критическое место с полным отсутствием такого "тотального" контроля (да и фактически вообще какого либо) - это таблицы, которые заполняются (юзаются) расчетными алгоритмами БД (те же архивы), на которые только стоят хитрые триггера "AFTER FOR EACH STATEMENT", запрещающие их любое изменение для любого процесса, кроме самих расчетов в БД, что опять же сделано для полного перекрытия кислорода любителям поправлять ручками расчитанные цифры. Все остальное, в том числе и FOREIGN KEY с этих таблиц снято с целью обеспечения максимальной производительности расчетов. Естественно не для каждой СУБД можно легко, просто и без потери производительности опускаться до такого "параноидального" проектирования БД, но с другой стороны если мне СУБД позволяет, то я не пожалею времени подстраховаться от человеческих ошибок :)