Конечно для случаев NVL(Field, DefaultValue) или NVL2(Field, NotNullDefaultValue, NullDefaultValue) это ничего не даст, но если для расчета значения по умолчанию используется функция (и еще через одно место написанная), то могут быть варианты.

В Oracle “умными” оказались только DECODE, CASE и COALESCE.

Отключить навсегда:

ALTER SYSTEM SET "recyclebin"=OFF SCOPE = BOTH;

Почистить для всех схем:

PURGE dba_recyclebin;

Зачем эта возможность добавлена, я так и не понял.

Если посмотреть на разницу в коде между sqm и sql – то 90% кода совпадает. Зачем тогда городить огород из еще одного языка?

Только что бы вместо такого кода

IF EXISTS(SELECT * FROM sys.objects WHERE object_id = object_id(N'dbo.sales') AND objectproperty(object_id, N'IsUserTable') = 1)
   DROP TABLE dbo.sales
GO
CREATE TABLE dbo.sales

писать одну команду DeclareTable(dbo.sales). Тем более что приведенные четыре строчки обычного копируются из ранее написанной процедуры и делается поиск и замена на нужное название.

Я соглашусь с использованием промежуточного языка для определения структур данных – это действительно удобно. Мы например просто определили формат для описания объектов в xml, и написали аж три xsl transformation stylesheets для oracle, mssql и mysql, это удобно не только для генерации кода, но и для поиска расхождений в базе и в модели.

Но для процедур? Как по мне это излишество. И ничего кроме десяти сэкономленных строк кода не даст.

Возможно это только начало. Примеры даны только для mssql, если бы код генерировался для нескольких баз данных – например для oracle и mssql – я бы обрадовался такому подходу. Кто-то решал это? Я сдался :) из-за oracle collections, оператора for x IN (…), exceptions и аналитических функций. (Глупо ориентироваться на самое слабое звено и использовать только те возможности которые есть у всех баз данных.)

Хотя справедливости ради скажу что и у нас процедурный код на Oracle “препроцессится” – точнее из разрозненных процедур генерируется код для заголовка пакета (интерфейс) и тело. Правда никакого макро-языка нет, а делает всё один простой скрипт на перле – которому дается имя каталога с процедурами и один создает интерфейс и код пакета.

Deferrable constraints нигде нет. Да и не пользовали никогда. Вообщем – случилось и случилось.

Пришлось написать скрипт который ловит такие записи. Что с ними делать потом решать Вам. Все результаты сохраняются в таблице Exceptions.

DECLARE
 
  QuantityTemp NUMBER(23);
 
BEGIN
   BEGIN 
        EXECUTE IMMEDIATE 'DROP TABLE  EXCEPTIONS CASCADE CONSTRAINTS';
   EXCEPTION
        WHEN OTHERS THEN
          NULL;
   END;  
 
   BEGIN 
        EXECUTE IMMEDIATE 'create table exceptions(row_id rowid, owner varchar2(30), table_name varchar2(30),  constraint varchar2(30))';
   EXCEPTION
        WHEN OTHERS THEN
          NULL;
   END;  
 
   FOR X IN 
   (
      SELECT Constraint_name, TABLE_NAME FROM user_constraints
   )
   LOOP
      EXECUTE IMMEDIATE 'DELETE FROM Exceptions';
      BEGIN
        EXECUTE IMMEDIATE 'ALTER TABLE ' || x.TABLE_NAME ||  ' MODIFY CONSTRAINT ' || x.Constraint_name || ' VALIDATE EXCEPTIONS INTO EXCEPTIONS ';
      EXCEPTION
         WHEN OTHERS THEN
            NULL;
      END;  
 
      EXECUTE IMMEDIATE 'SELECT Count(*)  FROM Exceptions ' INTO quantityTemp;
      IF QuantityTemp <> 0 THEN
         dbms_output.put_line('Table ' || x.TABLE_NAME || ' CONSTRAINT: ' || x.Constraint_name || ' HAVE ' || QuantityTemp || ' problems. ');
      END IF;   
 
   END LOOP;
END;

Вероятно Вам приходилось обфусцировать plsql пакеты Oracle. Вероятно также что однажды утилита wrap не смогла это сделать. И Вы получили примерно такую ошибку:

kgefec: fatal error 0
kgepop: no error frame to pop to for error 603

или другую ошибку подобную ошибку. И Вам приходилось рыскать в интернете – что же это такое, почему оно происходит, как с этим бороться и т.д.

Вы разбивали пакет на несколько пакетов, включали опцию /3Gb, обфусцирование делали где памяти немерянно, и т.д.

Всё это делали и мы, пока не оказалось, что вначале достаточно убрать лидирущие пробелы в коде (не руками конечно) перед обсуцированием.

Оказалось размер текста (не кода) критичен для обфускации и простым удалением лидирующих пробелов можно уменьшить текст процентов на 10-15%

И о чудо, гигабайта RAM достаточно для обфускации пакета размером в мегабайт. (Почему при этом используется 2.5GB RAM для меня загадка)

К счастью wrap в десятке делает все по уму, быстро и без излишнего использования памяти

Oracle 9.

Select Level from dual connect by Level < 200

Вернет строго 100 записей.

Select Max(Level) from dual connect by Level < 200

Вернет 199.

Приятно.

Но это еще не всё. :)

Select Max(LevelNo)
from
(
Select Level as LevelNo from dual connect by Level < 200
)

Тоже вернет 199

На Oracle 10 всё в порядке.

create view TestView as
Select Level as N from dual connect by Level < 10

Три следующих запроса работают нормально:

Select * from TestView;
Select N from TestView;
Select n from TestView;
Select "N" from TestView;

Не понравилось нам название колонки – N, меняем вьюшку

create or replace view TestView as
Select Level as "Test_Column"
from dual connect by Level < 10

Первые три запросы вернут ошибку ORA-00904. Последний четвертый выполнится без проблем.

Select Test_Column from TestView
Select test_column from TestView
Select "test_column" from TestView
Select "Test_Column" from TestView

Поначалу я решил что всё что заключено в двойные кавычки будет case-sensitive и надо обрамлять имя колонки в двойные кавычки и писать имя букву в букву с учётом регистра. Следующий пример это опровергает. Никаких проблем нет.

create or replace view TestView as
Select Level as "N"
from dual connect by Level < 10

Select * from TestView;
Select N from TestView;
Select n from TestView;
Select "N" from TestView;

Оказалось всё гораздно проще.

Если имя колонки заключенно в двойные кавычки, то при запросах его точно также и надо писать с учётом регистра.

Если в запросе вы обрамляете название поле двойными кавычками, то его надо писать в верхнем регистре, если конечно в определении view вы не использовали двойные кавычки.

Ну где у Оракла логика?!

% — всё что угодно

_ — один символ

Я всё время считал, что escape character в Oracle это тот же процент (%). До тех пор пока не пришлось искать в строках этот процент и подчеркивание. После первого же запроса понял, что одновременно интерпретировать один символ как «всё что угодно» и escape symbol как-то несподручно.

select * from something where like field like ‘%%%%’;

Бесмысленный запрос получается, с escape — тем более :)

select * from something where like field like ‘%%%%’ escape ‘%’;

Это эквивалент field = ‘%%’

Но вот не пойму, им что, было сложно сделать back-slash escape символом :(, что бы не писать каждый раз escape ‘\’

Dotnet framework 2.0.

OleDbDataReader.

Первые сто строк вычитываются нормально, потом все идет крокозяблами. Думал поседею.

Четыре разных сервера, три девятки, одна десятка, проявляется только на одном.

Проблемы оказалась в параметре FetchSize (сколько строк возращать за одну вычитку), первый раз все вычитается правильно, все последующие вернут мусор.

Пришлось ставить FetchSize = 100000

Нашел описание проблемы здесь. А вот решения кроме вышепредложенного пока нет.