Есть уйма софта, которая через OLEDB.ADO ломится на MSSQL.
Меняем МSSQL на ORACLE.
Многие софтины старые и глупые, а посему вставляют
в таблицу ''(пустые строки ) не пользуясь дефаултами.
Проблема №1:
в MS условие '' ='' — истинно, a ''=null -ложно
в оракле условие '' ='' — ЛОЖНО, a ''=null -ложно
Мне необходимо, чтобы оракл считал пустые строки
"равным" пробелу, а пробел равным пустой строке (как это делает MS)
Возможно ли так настроить оракл?
(Чтобы работало Select * from table where field ='')
Проблема №2:
Эти строки вставляются в поля на которых часто стоит NOT NULL,
что в оракле сразу же вызывает ошибку.
Дежурное решение — разрешить туда писать null.
Писать практически на каждую из 1000 таблиц
before insert — отвратительное решение.
Может есть что-то поизящнее?
Проблема №3:
Можно ли OLEDB.ADO настроить так,
чтобы он на своем уровне пустые строки заменял пробелами
при передаче параметров от клиента к серверу?
Т.е. на клиенте я вызываю хранимую процедуру
со строковым параметром равным пустой строке,
а на сервак на месте этого параметра приходит пробел.
Здравствуйте, kto-to, Вы писали:
KT>Проблема №1:
KT>в MS условие '' ='' — истинно, a ''=null -ложно KT>в оракле условие '' ='' — ЛОЖНО, a ''=null -ложно KT>Мне необходимо, чтобы оракл считал пустые строки KT>"равным" пробелу, а пробел равным пустой строке (как это делает MS)
KT>Возможно ли так настроить оракл? KT>(Чтобы работало Select * from table where field ='')
RTRIM(field) = RTRIM('') -- справа не нужно, все равно пустая строка
RTRIM "съедает" справа в данном случае пробелы, а вообще можно указать вторым параметром, строку, содержащую символы, которые надо удалить.
Здравствуйте, kto-to, Вы писали:
KT>Есть уйма софта, которая через OLEDB.ADO ломится на MSSQL. KT>Меняем МSSQL на ORACLE. KT>Многие софтины старые и глупые, а посему вставляют KT>в таблицу ''(пустые строки ) не пользуясь дефаултами.
Есть впечатление, что Вы хотите парой волшебных движений за час перевести систему с сервера на сервер. Думаю, это не удастся; при всех оптимизациях это серьезная работа (не говоря уже о необходимости полного тестирования).
Я бы в первую очередь вставил некий промежуточный уровень между системой и сервером; в частности, он отрабатывал бы эти инсерты, удаляя "лишние" поля. На дельфе это сделать легко; как в Вашем случае — трудно сказать
Что касается нуллов — вопрос к физическому смыслу данных. Если в полях должна лежать пустая строка, и это именно дефолт — правильным будет именно сделать поле нулловским.
старое приложение делает так
1) insert into table(field, pk) value('','pkvalue')
2) здесь, на уровне БД/OLEDB.ADO сейчас ничего не происходит,
а вероятно должно (например тригер или какая-то настройка в OLEDB.ADO)
3)потом старое приложение используя свой старый
код спрашивает
select * from table where field =''
а на выходе должно получить эта строку
(ЭТА ЗАДАЧА ПОХОЖЕ СОВСЕМ НЕРЕАЛЬНАЯ)
4) еще старое приложение используя свой старый
код может спросить
select field from table where pk ='pkvalue'
а на выходе должно получить не нулл,
т.к по нулу станут валиться многие участки кода.
Можно написать тригер before insert for each row,
который будет заменять пустуюстроку на пробел,
но где гарантия, ___что он выполнится саммым первым___,
т.е первее всех других триггеров этого типа.
Кроме того это решение мне не нравится по 2-м причинам:
1-главная) практически накаждую из 1000 таблиц будет такой триггер
2) в ms 'a'+field+'b' и в оракле 'a'||field||'b' дадут разные результаты
Здравствуйте, Softwarer, Вы писали:
KT>>Есть уйма софта, которая через OLEDB.ADO ломится на MSSQL. KT>>Меняем МSSQL на ORACLE. S>Есть впечатление, что Вы хотите парой волшебных движений за час перевести систему с сервера на сервер. Думаю, это не удастся; при всех оптимизациях это серьезная работа (не говоря уже о необходимости полного тестирования).
С этим никто не спорит!
Но хотелось бы по максимуму облегчить задачу программерам
+ побыстрее получить достаточно функциональную альфа версию
S>Я бы в первую очередь вставил некий промежуточный уровень между системой и сервером; в частности, он отрабатывал бы эти инсерты, удаляя "лишние" поля. На дельфе это сделать легко; как в Вашем случае — трудно сказать
этот промежуточный уровень уже есть OLEDB.ADO
S>Что касается нуллов — вопрос к физическому смыслу данных.
Вопрос не в нулах а комплексном решении проблемы.
Здравствуйте, kto-to, Вы писали:
KT>Но хотелось бы по максимуму облегчить задачу программерам KT>+ побыстрее получить достаточно функциональную альфа версию
А в чем цель? Когда стоит такая задача — обычно уже есть готовая система, то есть уже первая версия должна быть надежной (чтобы на нее можно было перенести реальную базу).
Насчет облегчения задачи — я вижу два момента. Во-первых, нужно предсказать проблемы и вляпаться в те, которые не удалось предсказать. Для этого подходит перевод некоторого замкнутого модуля достаточно небольших размеров. Во-вторых, нужно найти решение этих проблем.
Скажу сразу, "настройку" типа запрошенной Вами я к решениям не отношу — даже если оно возможно. Инструментом надо пользоваться в соостветствии с его правилами, иначе не имеет смысл переходить. От "глупостей", унаследованных исстари таким образом, потом избавиться практически невозможно.
Решений имхо есть две категории. Во-первых — некий стандартный код. Скажем, если у вас в приложениях повсеместно используется класс, допустим, ADOQuery — я бы начал с того, что унаследовал от него свой в точности такой же класс и везде в приложениях заменил бы один на другой. Далее, все что можно, я бы решал на уровне этого наследника — скажем, в том же случае пустых строк в инсерте я бы на уровне этого наследника модифицировал insert, и одновременно писал бы диагностику программистам — мол, еще вот здесь надо поправить. Таким образом, сначала все работало бы, а постепенно можно будет исправить все такие места и после этого выкинуть эту некрасивую вставку из своего класса.
Во-вторых — формализованное действие, которое должны сделать программисты "во всех местах, где". Тут главное — найти все такие места. Опять же: потребуется проверить все SQL-и, чтобы в них не было того же "равно пустой строке" в where. Тут, например, на уровне того же класса запроса можно отлавливать такую строку и давать задание программистам — исправить.
KT>этот промежуточный уровень уже есть OLEDB.ADO
Это провайдер, вмешаться в работу которого вряд ли возможно (хотя я не знаю ADO — может, и позволит). А нужен — логический уровень, уровень абстракции, который поможет Вам аккуратно перейти.
P.S. На самом деле у меня есть мнение, что такой уровень имеет смысл закладывать всегда — вплоть до того, что при разработке приложения сразу делать свои тривиальные обертки вокруг любых используемых классов. Правда, сам я так не делаю — пока что достаточно легко добавить такой тривиальный класс, когда в нем возникает необходимость.
S>>Что касается нуллов — вопрос к физическому смыслу данных. KT>Вопрос не в нулах а комплексном решении проблемы.
Комплексного решения здесь, насколько я в курсе, нет. И это, пожалуй, к лучшему — не знаю кто как, а лично я очень не люблю "переключателей логики".
