Devart Forum

Nag

Обновился до версии 3.1.190.1. Переход из дерева объектов к реализации метода внутри пакета вобще перестал "фунициклировать". Раньше хоть в большей части случаев (кроме наличия комментов или символов $ в наименовании метода) всё работало. Теперь просто открывается тело пакета с курсором на первой строке - и всё. Лучше уж верните как было.

Особенно забавно при этом читать в списке исправлений:
Incorrect navigation to package functions and procedures is fixed (T36445)

А-ля, "исправлено методом отключения".

Nag

а добавить в редактор таблицы поддержку создания/просмотра индексов по выражению не планируется?

Nag

Коли речь зашла про редактор таблицы, то есть пожелание в контекстное меню добавить пункт а-ля "Скопировать список полей в буфер", при выборе которого в буфер обмена попадает список наименований всех полей таблицы через разделитель (CR, TAB и т.п.)

Nag

Мне сие понадобилось в связи с написанием сразу "комплекса" триггеров на одной таблице для обхода mutating table: операторного BEFORE, "строчного" и операторного AFTER. Все они должны быть "включены" одновременно. Но их разработка, естественно, происходит последовательно и занимает некоторое время, в течение которого над таблицами продолжают выполняться DML-операторы. И нет никакой гарантии, что между созданием триггера и его последующей деактивацией не успеет "что-нибудь" выполниться.

Nag

Alexander писал(а):Данная опция становится активной после сохранения триггера (Ctrl+S).

Спасибо, капитан Очевидность! Это я в курсе. Речь шла именно про создание триггера в состоянии DISABLE, а не про отключение уже существующего триггера.

Nag

З.Ы. Аналогичное предыдущее замечание про compound-триггер так и осталось "безответным"

Nag

При создании нового триггера на таблицу в окне редактора триггера checkbox "Включить" сразу отмечен и недоступен для изменения. Как создать триггер, чтобы он не был сразу активен?
Понятно, что я могу ручками выполнить команду CREATE TRIGGER с опцией DISABLE. Но как-то при таком подходе теряется смысл визуальных "мышекликательных" редакторов, призванных облегчить жизнь рядовых программеров БД.

Nag

Открываем SQL-редатор, набираем текст запроса. Например, такой

Код: Выделить всё

select * from v$session_con

Вызываем окошко дополнения кода (Ctrl+Space)

Зажимаем Shift+ и выделяем часть текста (количество выделенных символов значения не имеет, главное, чтобы выделение было до ключевого слова FROM, чтобы не пропало всплывшее окно дополнения).

Завершив выделение, нажимаем любую буквенно/символьно/цифровую клавишу, чтобы заменить выделенный текст выбранным символом.
В итоге, лицезреем окошко с сообщением о непредвиденной ошибке.

Nag

Кажется, нас проигнорировали...

Nag

Собственно, сабж.
В редакторе табличного триггера на вкладке "Событие" в radio-группе "Момент срабатывания" можно выбрать только "После" и "До", а надо ни то, ни другое. Ну либо "оба два"

Смотря как посмотреть, пардон за тавтологию. В общем, надо бы поддержку составных триггеров.

Nag

Присоединяюсь!
Хоть этот вопрос уже где-то на форуме и поднимался, но не лишним будет еще раз напомнить о сей злободневной болячке.

И вообще, IMHO, кроме сохранения при краше не плохо было бы, чтобы была настройка а-ля "Сохранять окружение при отключении/выходе" и если она активна, чтобы при закрытии приложения и/или отключении от базы оно само молча сохраняло текущее состояние: какие редакторы открыты, окна SQL-редакторов сохраняло всей "кучей" вместе с содержимым, не предлагая назойливо сохранить каждое из них по отдельности в файлы. А при подключении "восстанавливало" эти окошки обратно.

Nag

Создаем таблицу и триггер:

Код: Выделить всё

create table tt2 (
  f01 number not null,
  f02 number);

Код: Выделить всё

create or replace trigger tt2_biu
before insert or update on tt2 for each row
begin
    :new.f02 := coalesce(:new.f02, 0);
end tt2_biu;

Обновляем дерево объектов, находим триггер TT2_BIU, двойным кликом открываем редактор. В нем переименовываем триггер

Теперь компилируем (Ctrl+F7). Получаем жизнерадостное сообщение, что триггер с новым именем TT2_CHANGED_BIU был успешно скомпилирован, что дополнительно визуально подтверждается и изменением текста узла в дереве объектов с TT2_BIU на новое имя. Довольно потирая руки и злорадно хихикая ставим фокус на дерево объектов и обновляем его (F5).

Дальше остается только выглянуть в окошко, проверяя: уж не весна ли там наступила? А то что-то триггеры как кролики стали размножаться...

Nag

Создаем таблицу

Код: Выделить всё

CREATE TABLE TT2 (
  F01 NUMBER NOT NULL,
  F02 NUMBER NOT NULL);

Открываем ее редактор, переходим на вкладку "Ограничения", открываем реадктор ограничения для столбца F02 и...

о, чудо! видим в открывшемся редакторе ограничение для столбца F01

Но нас не так-то просто сбить с толку! Идем дальше. Создаем триггер для нашей таблицы

Код: Выделить всё

CREATE OR REPLACE TRIGGER TT2_BIU
BEFORE INSERT OR UPDATE ON TT2 FOR EACH ROW
begin
    :new.f02 := coalesce(:new.f02, 0);
end;

Обновляем дерево объектов, находим наш новый триггер, открываем его в редакторе. Возвращаемся в редактор таблицы TT2, переходим на вкладку "Общее", дважды щелкаем на строке с полем F02, в открывшемся редаторе "Свойства столбца" отмечаем галочку "Пустые значения", жмякаем OK. Сохраняем изменения таблицы (Ctrl+S). И долго втупляем в появившееся сообщение "Объект TT2_BIU был удален. Хотите закрыть редактор?"

Честно говоря, меня аж холодный пот прошиб в первый раз, когда на таблице висело штук 5 потом и кровью выстраданных триггеров, все их редакторы были открыты и после сохранения изменений таблицы мне было сообщено, что все они благополучно удалены. После первой бурной реакции, выражавшейся трехэтажным матом, было огромным облегчением узнать, что бага достаточно безобидная и на самом-то деле не удаляет триггеры, а только запугивает наивных юзверов, чтобы не расслаблялись. Но все равно неприятно...

Nag

Пишем в SQL-редакторе нечто такое

Код: Выделить всё

select
    t.f01,
    t.f02
from
    tt2 t
where
    t.f01 = 0

Выделяем весь текст (Ctrl+A), вызываем диалог замены (Ctrl+H), указываем в полях:

Найти=t.
Заменить на=ft.
Искать в=Выбранном
Опции поиска=

Нажимаем "Заменить все" и... висим, висим, висим...
Если заменять "t." на, скажем, "s.", то всё ОК. Очевидно, трабла в том, что поиск тупо зацикливается, постоянно натыкаясь на подстроку, которую он на самом деле уже заменил.

З.Ы. версия dbForge Studio for Oracle 3.1.172.1

Nag

IMHO, крайне неудобно работать с сеткой, отображающей результаты выполнения запросов на вкладке "Данные" в SQL-редакторе в случае, когда результирующий набор данных "широкий" (т.е. имеет достаточно много колонок) и количество строк превышает несколько "экранов". По нажатию Ctrl+End активной ячейкой в сетке становится "правая нижняя", а хотелось бы, чтобы активной становилась ячейка последней строки ТЕКУЩЕЙ колонки. Аналогично с Ctrl+Home.
Или может есть какое-то другое сочетание клавиш для перемещения на первую/последнюю строку в текущей колонке?

Devart Forum

Найдено 60 результатов

переход к реализации метода пакета - всё сломалось

создание триггера в состоянии DISABLE

бага с дополнением кода

как создать compound-триггер?

один триггер - хорошо, а два - лучше!

Еще пара глюков

зацикливающаяся замена - ржунимагу

сетка данных - небольшая "хотелка"