Отчёт о тестировании SQLDetective 5.1.1.316, опубликованном 31 марта 2020 года. Проверки проводились по Release Notes. Незадолго до этого обновления компания ConquestSS заспамила потенциальных покупателей предложением о небывалой скидке - пара продуктов (CDB+SD) за полцены, а сразу после публикации текущего билда завалили предложениями о покупке только SD, но также с 50% скидкой. Обычно такие кампании проводились в период застоя (неделя конца августа), а эта почти месячная акция заставляет задуматься - не закрытие ли производства предполагается? Надеюсь, вы уже сами сможете понять "какого бага билд", ознакомившись с моим отчётом.
IMPROVEMENTS 0+0.5+0.7=1.2 из 3 возможных, -1-0.8-1-0.3=-3.1 за баги
Preferences 0 из 1 возможного, -1 за баги
• Removed the “Notify about AMS expiration” check box from the License Key page.
Убран чек-бокс для предупреждения об окончании периода оказания сервиса поддержки со страницы лицензионного ключа.
Структура RNs подразумевает блок удалений, но этот пункт оказался в группе новшеств. Поэтому, кроме проверок по чит-листу для опций, необходимо протестировать систему AMS, то есть поискать изменения в лицензионном соглашении или в других источниках на предмет оказания техподдержки. Примечание: убранная опция имела иное наименование в режиме ограниченной по времени версии (в нашем обычном случае - триал). С интерфейсной точки зрения новшество, а вернее - удаление, выполнено. Поскольку хелп не менялся с 28/11/2019, то в нём до сих пор имеется инфа про возможность сократить спам. К тому же, в хелп-топике "Preferences – License Key" всё ещё нет описания давно появившейся кнопки "Update License.." на странице лицензионного ключа настроек приложения. Функционально напоминания переместились из самостоятельного окна трея в панель системных предупреждений, о чём ни слова не сказано в RNs и хелпе. Никак не могу сказать, что это новшество чем-то улучшило работу пользователя с приложением, поскольку юзер теперь не может управлять спамом. Стоит пояснить, что предупреждения появляются автоматически при каждом старте приложения с увеличивающейся регулярностью при приближении даты очередного платежа: за месяц, за неделю, за 5-4-3-2-1 дней. В случае многопользовательской лицензии админа продукта затерроризируют пользователи без выхода в инет своим неравнодушием и предупредительностью. Во избежание именного этого раздражения изначально и была введена эта опция. Поэтому описанное новшество считаю именно ухудшением, а не улучшением. Если бы QA вовремя вмешался в планирование фиксов, то это ухудшение не было бы внедрено. Поэтому пункт RNs не получает вроде бы заслуженный балл (сделано во вред юзеру) и к тому же теряет ещё балл за неполноценность исполнения (текст RNs ограничен одним случаем и не упомянут функциональный перенос, хелп не актуализирован).
Нотификации об окончании периодов тех.поддержки не единственные перенесены в системную панель. Код модуля OSD обрабатывает всё, связанное с тех.поддержкой, видимо поэтому и конфирмация о сохранении (полагаю, и об отправке) OSD-сообщения перенесена из самостоятельного диалога в панель системных предупреждений. Об этом изменении функционала не упомянуто в RNs, да вдобавок оно принуждает пользователя к дополнительным переживаниям (подтверждение не входит в рабочую область приложения, а значит теряется из области видимости) и телодвижениям (системная панель - это соседнее окно, которое нужно активировать отдельно от работающего приложения). Скрытые переделки такого рода вынуждают снимать баллы с билда: -0.5 за само изменение функционала и -0.3 за не оповещение юзера.
Session Navigator 0.5 из 1 возможного, -0.5-0.5=-1 за баги
• Added all missing fields to the Process tab and the most frequently used ones are now displayed by default.
Добавлены все забытые поля на страницу процессов и более востребованные теперь отображаются по-умолчанию.
Подразумеваю, что данное новшество зависит от версии базы данных. Скорее всего в Oracle 12-ой версии и более последних добавились параметры отслеживания сессионных процессов. К сожалению, тех.писательница этого не упомянула. Искать дополнительно подсказки в хелпе бесполезно, потому что он давно (с ноября 2019г.) не актуализирован. Видимо совмещение тех.писательницей функций маркетолога (именно она спамила потенциальных покупателей) не позволяет ей управляться с двумя должностями одновременно. Полноценно проверить новшество у меня нет возможности по двум причинам: 1) до сих пор работоспособность модулей Session Navigator и Top Session Locator не приведена в надлежащий вид из-за проблемы при перекодировке юзера системы (запрос "select osuser from v$session" для всех системных сессий возвращает иероглифы, при том что для сессий приложения отрабатывает благополучно); 2) нет баз Oracle различных версий. Но список полей даже в модуле без данных сравнить с предыдущей версией SD вполне доступно: к ранее имевшимся двенадцати полям добавились ещё тринадцать, но не из системного вьювера процессов, а из системного вьювера сессий и может ещё какого-то (отследить запрос не удаётся из-за бага с системным юзером).
Примечание: отслеживать запросы можно тем же модулем Session Navigator, но в предыдущих версиях SD, например, 4.4 или 4.7.1, которые иначе обрабатывали юникод. Возможно список полей стал более обширен, но список колонок в Dataset Manager абсолютно пустой. Это означает что, либо в грид по-умолчанию выведены все поля, а не только часто используемые, либо проблема с системным юзером не позволяет мне оценить полноту новшества и параметры процессов можно настроить в большем количестве, либо ограничение версии базы позволяет оценить лишь доступные добавления. В любом случае, новшество как-то осуществлено, но даже элементарный функционал мне не удалось проверить. Поэтому пункт RNs получает лишь 0.5 балла за наличие и теряет -0.5 из-за древнего бага.
В процессе локализации бага "partial multibyte character" обнаружилась проблема с настройкой тулбара для области SQL History в окне SQL Editor. Это не новый баг текущего билда. Его появление зависит от каких-то изменений в модуле Icon Dictionary, поскольку теперь тулбар истории запросов абсолютно невозможно настроить - любой клик в IDic оставляет на тулбаре истории запросов редактора лишь одну кнопку копирования текущего текста в новую закладку редактора. Это серьёзный интерфейсный баг для SQL Editor из-за отсутствия обходных путей, поэтому билд теряет ещё -0.5 балла.
Code Editor 0.7 из 1 возможного, -0.3 за баги
• All occurrences of selected text are now highlighted in the Code Editor.
Все случаи выбранного текста теперь подсвечиваются в редакторе кода.
Очень странная формулировка новшества, из которой абсолютно не понятно о каких выборках текста идёт речь. На ум приходит только функция поиска по тексту, либо подсвечивание имён объектов при работе "Ctrl+Click". Если бы тех.писательница более тщательно подбирала термины из общепринятого глоссария, то вместо слова "selected" было бы "searching" и у меня не возникло бы никаких проблем с пониманием новшества. Интуиция меня не подвела, все искомые символы теперь подсвечиваются жёлтой подложкой сразу после позиционирования курсора на первом найденном. Тестирование осуществляем на любом своём тексте, набранном или вставленном в SynEdit (область редактора кода в SQL Editor, Stored Program Editor). В обычном текстовом редакторе (дополнительное окно для символьного поля в гриде данных) ничего подобного не приделано. Результаты моих исследований поиска в редакторе кода не утешительны. Новшество не доделано в двух направлениях: 1) настройки приложения не обрели новую опцию, то есть жёлтый цвет ни на что иное не сменить, что может быть опасно наложением и смешиванием раскраски; 2) первое найденное вхождение первоначально подсвечивается серым (по-умолчанию), а после перехода курсора на следующее вхождение (по F3) его подсветка обнуляется вместо замены на жёлтую подложку (ещё веселее случай поиска с середины кода). Если же поиск осуществляется в пределах предварительно выделенного (подсвеченного) текста, то подсветка последующих найденных вхождений отрабатывает достаточно логично. В процессе тестирования поиска в рамках выделенного текста выяснились баги: 1) при достижении предела текущего направления поиска больше не предлагается возобновить его с первоначально искомой позиции; 2) смена направления поиска при достижении предела в рамках выделенного текста всё ещё предлагает возобновить поиск с исходной позиции, но при этом границы поиска обнуляются: нет расцветки, исходная позиция приравнивается к началу/концу всего кода. За усовершенствование могу дать лишь 0.7 балла и за баги сниму 0.3 балла.
BUGS FIXED 0.5+1+0+1+0+1+0+0=3.5 из 2+5+1+2+1+1+1+1=14 возможных
Core 0.5+0=0.5 из 2 возможных
• Fixed the error “Could not initialize taskbar. Error:-2147467263” when running SQLDetective on Windows Server with Citrix.
Исправлена ошибка инициализации таскбара при запуске приложения на специализированной системе.
Это фикс бага из числа CustDev (индивидуальная разработка). Вероятно, какой-то перспективный покупатель пренебрёг системными ограничениями, описанными в ReadMe, инсталляционном мастере и на сайте компании ConquestSS, где указаны лишь конкретные операционные системы. Указанная в баге вариация платформы не является распространённой, поэтому фикс авансом примем на веру, перенаправив его проверку конкретному пользователю, зарегистрировавшему проблему. За такие индивидуальные правки можно получить не более 0.5 балла.
• Files in UTF-8 (with no BOM) and UTF-16 are now imported and analyzed correctly.
Файлы определённого сочетания юникодности теперь импортируются и анализируются правильно.
Текстовка бага ограничивает тесты особыми форматами текстовых файлов, путает понимание наличием терминов "импорт", "анализ" и "правильно". О каком импорте в данном случае идёт речь? Импорт данных в соответствующем мастере или открытие текстового файла в редакторе кода? Анализ кода в редакторе имеется ввиду или анализ объекта базы по командам ALTER, ANALYZE? Какие конкретно правила теперь учитываются и для каких действий и условий, если опираться в тестах на термин "правильно"? Ни один из вопросов не проясняется за счёт причисления пункта RNs к блоку Core. Такая размытая формулировка даёт мне право не включать фикс в билд. Чтобы не выявить массу дополнительных багов, как несоответствие термину "correctly", не буду проводить тесты гипотез. Поэтому только 0 баллов.
Примечание: если вам сильно захочется помучаться и поискать фикс, то тестовые данные - файлы - создавайте изначально в независимом стабильном приложении - Блокнот OS Windows. Символы можно набирать через альтернативный ввод: удерживая ALT набрать трёх-пятизначный ASCII-код символа. Внимательно выбирайте юникодные параметры сохранения файла, которые доступны в ниспадающем списке диалога сохранения файла.
SQL Editor 0+0.5+0.5+0+0=1 из 5 возможных
• The SQL Editor no longer hangs if the script execution is suspended after an error.
Редактор больше не зависает, если исполнение скрипта отсрочено после ошибки.
Для проведения тестирования необходимо удостовериться, что модуль настроен должным образом. Для этого откроем страницу "Preferences \ Code Editors \ SQL Editor" в установках приложения и проверим статусы опций "Prompt to break execution for all statements" (диалог позволяет обрабатывать исполнение скриптов в ручном режиме) и "Suspend script execution on error" (включенный режим откладывает выполнение после ошибки автоматически). В предыдущих билдах исполнение любого скрипта, даже без ошибок, подвешивало окно процесса исполнения после второго-третьего запуска скрипта. В текущем билде этот диалог не мозолит глаза, но после его исчезновения всё окно SQL Editor теряет всяческое управление: на тулбаре нет ни одной рабочей кнопки, закладки не реагируют на клики мышью, контекстное меню не появляется даже по нажатию функциональной клавиши на клавиатуре, лишь некоторые глобальные экшены доступны по горячим клавишам (поиск "Ctrl+F" не срабатывает, но запуск скрипта "Ctrl+Enter" или обновление данных "F12" происходит). Благо, закрытие окна доступно без проблем и дополнительных средств. В отличие от предыдущего билда, диалоговое окно процесса переименовано в авто-детектирование плана исполнения, но набор интерфейсных элементов остался прежним. Так что могу заключить, что фикс не решает проблему. Программист что-то изменил, но никакой ощутимой пользы юзеру не предоставил. Поэтому пункт RNs не получает ни балла.
• Removed the limit on the number of characters in a single line.
Убран лимит на количество символов в одной строке.
В предыдущем билде в редакторе кода (SQL Editor, Stored Program Editor), окне для вывода результатов запроса "SQL Editor / SQL Output" и текстовом редакторе (дополнительное окно для просмотра и ввода значений в символьные поля модуля SmartDataset) количество символов одной строки ограничивалось 1024 или 255 позициями. Но, если в редактируемые области ещё можно было вставить из буфера не ограниченное количество, то вывод значений запроса почему-то был обойдён вниманием программиста. Поправили возможность набивать символы в одну строку более 1024 символов, но строки в SQL Output окне и даже при spool-команде в файл всё-ещё обрезаются после 255 знаков. Этот баг выяснился мной в процессе подготовки статей о юбилярах по годам, поэтому пришлось воспользоваться не удобствами SD, а надёжностью SQL*Plus, который не обрезает, а всего лишь переносит длинные строки.
Кстати, SD не жалует команду переноса строк: никакие настройки приложения не соблюдаются (в установках количество символов 1000 и включен перенос, а в выводе - только 255 в одну строку), даже с включенным параметром переноса "set wrap on" скрипт выполняет обрезание строк вывода. За половинчатое решение проблемы (редактор кода исправлен, но модуль вывода - нет) билд получает лишь полбалла.
• Fixed the splitter positioning on maximizing/restoring the window.
Зафиксировано позиционирование разделителя при максимизации и восстановлении окна.
Интерфейс SQL Editor имеет пять сплиттеров в разных местах: между редактором и закладками для отображения результатов, в двух закладках с результатами, между деревом кода и редактором, между историей запросов и редактором. О каком из них речь в данном пункте? Это придётся выяснять в исследовательских тестах. А чтобы выявить уровень регрессии к вариантам сворачивания и максимизации окна следует добавить его закрытие/открытие в режимах максимизации и средней величины, а также статус свёрнутости межсплиттерных панелей.
В общей сложности получается 60 тестов, которые надо выполнить на двух билдах - прошлом (выявить места багов) и текущем (убедиться в полноте мест исправлений). Да, некоторые общевидимые вариации можно примечать единым тестом, что сократит ваше рабочее время. Такую компоновку причисляю к комплексному тестированию. Зелёным помечаем положительные изменения, красным - недоправки, жёлтым - отсутствие надобности фиксов. Поскольку исправлено поведение только главного сплиттера при прижимании, а не пиксельно-процентном соотношении высот панелей, и совсем не исправлено изменение ширины панели историй запросов, то пункт меню, недобросовестно описанный тех.писательницей, приносит билду лишь 0.5 балла.
• Fixed the ability to view data of the referenced object type.
Поправлена возможность просмотра данных ссылочных объектных типов.
Если вы хорошо знакомы со структурой объектов базы данных Oracle и возможностями приложения SD, то интуиция может вывести вас, как и меня, на таблицу с объектными полями, либо на объектную таблицу, два типа запросов из которой выполнены в закладку Data Output. Первый тип запроса - прямое перечисление полей, а второй - через спецсимвол звёздочки "select * from". Для теста нам нужны будут две таблицы на основе объектных типов: вся таблица и лишь некоторые поля. Пример возьмём из документации по базе данных Oracle.
-- создаём объектный тип "obj1" с двумя атрибутами "fld1" и "fld2"
CREATE TYPE obj1 AS OBJECT (fld1 VARCHAR2(100), fld2 NUMBER)
NOT FINAL;
/
-- создаём объектную таблицу "obj_tbl" на основе объектного типа "obj1"
CREATE TABLE obj_tbl OF obj1;
/
-- создаём таблицу "obj_fld_tbl" с полем "obj_fld " на основе объектного типа "obj1"
CREATE TABLE obj_fld_tbl (tb_fld number, obj_fld obj1);
/
Для обеих таблиц генерим (перетаскивание объекта из дерева Object Navigator предлагает тексты запросов "Select *" и "Select All") в SQL Editor запросы двух типов. Грид таблицы "obj_tbl" в обоих случаях состоит из двух столбцов, а гриды таблицы "obj_fld_tbl" состоят из двух и трёх столбцов для запросов "Select *" и "Select All" соответственно, как в предыдущем, так и в текущем билдах. Для каждого поля при необходимости открывается дополнительный редактор соответствующего типа (калькулятор, текстовый редактор или грид ссылочных полей). В этом плане между билдами тоже нет никакой разницы, из чего заключаем, что либо никакого фикса не сделано, либо тех.писателю было объяснено исправление программистом не точно, либо у тех.писательницы не хватило знаний для конкретизации фикса в рамках текста RNs. Отсутствие изменений даёт мне право на нулевой балл.
• Fixed parsing of the quotes in the SQL*Plus comments (REM).
Исправлено вычленение кавычек в комментариях SQL*Plus.
SQL Editor предназначен для исполнения не только команд SQL, но и специфичных для SQL*Plus действий. Комментарий в скрипте может быть трёх типов: однострочный после двойного минуса или REM символов, многострочный в окружении слешей и звёздочек. Кавычки в коде могут быть одинарными, двойными и альтернативными. Поскольку в RNs не указан тип кавычек, то исследуем изменения в билде для всех трёх типов, но альтернативные глянем лишь одной вариации, чтобы не превращать тесты в бесконечность. Хотя вполне возможны баги в каких-то не указанных вариациях. Для достоверности тестов будем использовать одинаковые кавычки в закомментированной и исполняемой части скрипта. Обращать внимание стоит на графическое (цветовое) отображение текста в редакторе (интерфейсный компонент SynEdit) и результат от исполнения скрипта (на закладке SQL Output), поскольку тех.писательница не указала предмет применения парсера.
В прошлом билде никаких проблем при исполнении скрипта с кавычками в комментариях не было. В текущем билде заметно только отображение результатов, но отмеченная в RNs команда REM не претерпела вообще никаких изменений. Поэтому пункт RNs не получает ни балла из-за полного несоответствия текста фикса новому функционалу.
Stored Program Editor 0 из 1 возможного
• An access violation error no longer occurs on the stored program execution.
Ошибка доступа больше не случается при исполнении хранимой программы.
Поскольку не конкретизирован тип исполняемой программы и причины ошибки, то попытаемся воспроизвести баг на любом объекте. И поскольку предыдущий билд исполняет благополучно первую попавшуюся мне процедуру, то этот мнимый фикс получает звание приписки и не даёт билду ни балла.
Session Navigator 0.5+0.5=1 из 2 возможных
• The error ‘’‘is not a valid integer value.’ no longer occurs when there are no results to show in the filtered Session Navigator.
Ошибка инвалидного целого значения больше не случается, когда в отфильтрованном навигаторе сессий нет результатов для отображения.
К сожалению, навигатор сессий не работает с базой из-за проблемы с системным юзером. А не имея иных машин для тестирования проверить фикс не могу. Авансом на веру дам 0.5 балла.
• Fixed the ability to kill database sessions in the RAC instance.
Исправлена возможность убивать сессии базы с распределённым доступом.
На моём тестовом стенде не только не работает модуль навигатора сессий, но и нет базы с распределённым доступом. Поэтому авансом на веру дам 0.5 балла.
Database Connection 0 из 1 возможного
• An access violation error no longer occurs on trying to connect to a new database after the previous connection was lost.
Ошибка доступа больше не случается при попытке коннекта к новой базе после потери предыдущего коннекта.
В данном случае необходимо определиться в понятиях "новый коннект" и "потеря предыдущего". Поскольку основное окно коннекта к базе имеет список последних коннектов, то предполагаю, что "новым" коннект должен быть для этого списка, то есть надо подключаться либо юзером, либо именем базы, либо её типом, не имеющим аналогичное сочетание в списке предыдущих коннектов. Потеря коннекта может быть разных видов: физическая - отключение рабочего компьютера от сети/сервера с базой, логическая - убивание или отсоединение сессии средствами администратора базы. Важным моментом надо считать текущий модуль приложения, выявивший потерю сеанса, и работоспособность мониторинга коннекта через настройку "Preferences \ General \ Session \ Keep connection alive - png DB every [NN] seconds". Также не лишней будет гипотеза о превышении граничных значений: 1) окно коннекта имеет опцию в 20 сохранений по-умолчанию предыдущих удачных коннектов; 2) SD можно настроить на разрешение только одной сессии базы в рамках запущенного приложения "Preferences \ General \ Session \ Only one connection per SQLDetective instance". Ещё одним аспектом тестирования этого фикса можно считать наличие в приложении простого окна коннекта к базе, которое можно вызвать командой connect в SQL Editor. Какой из пяти вариантов давал ошибку в прошлом билде? Придётся искать тестировщику, потому что тех.писательница поленилась уточнить условия, то есть актуализировать баг. Мне не удалось воспроизвести баг в прошлом билде по догадкам, поэтому пункт RNs остаётся без баллов.
Database Connection Options 1 из 1 возможного
• The error that is shown on trying to add a new database connection type with the existing connection type name is no longer handled by EurekaLog.
Ошибка, которая показывается при попытке добавить новый тип коннекта к базе с существующим именем типа коннекта больше не отслеживается утилитой EurekaLog.
Тех.писательница в попытке конкретизировать баг наворотила текст, который вполне можно было уместить в меньшее количество словарных оборотов: добавление дубликата типа коннекта обрабатывается как внутренняя ошибка приложения вместо общесистемной. Стоит пояснить, что внешняя утилита EurekaLog отслеживает большинство ошибок приложения и некоторые проблемы базы, формируя системные логи. Если юзер сам добавил дубликат в число типов коннектов, то это не может быть ошибкой системы и должно обрабатываться интерфейсом приложения. Описанная обработка существовала в SD прежних версий, до перехода программистов на современный компилятор DelphiXE. Для воспроизведения в предыдущем билде откройте окно опций коннекта из окна последних коннектов, в блоке Database Type кликните по кнопке с плюсиком и введите наименование, аналогичное видимому в комбобоксе, после клика по кнопке подтверждения оцените окно и текст ошибки. Этому регресс-багу уже пятый год. Полагаю, что его отыскали в закромах BTS и включили в билд лишь для массовости правок, потому что у подобной мелочёвки обычно очень низкая важность. Но, тем не менее, он приносит целый балл.
Code Insight 0 из 1 возможного
• The exception “Object lock not owned.” no longer occurs when the Code Insight window is opened when a huge script is loaded in the SQL Editor or Stored Program Editor.
Исключение об отсутствии владельца блокированного объекта больше не срабатывает, когда окно помощника кода открыто для огромного скрипта, открытого в редакторах кода.
Для воспроизведения бага в прошлом билде вам придётся самостоятельно определить огромность скрипта, исходя из системных возможностей вашего компа. Для некоторых тестовых стендов несколько лет назад губительным был размер в два мегабайта, для иных - в десять мегабайт или 500 килобайт. Реальные юзеры присылали в тех.поддержку тела пакетов в сотни тысяч строк, так что можете начать с простой дублированной процедуры. Перед открытием файла в редакторе убедитесь, что подсказчик кода сработает автоматически, для чего достаточно установить настройки по-умолчанию на странице "Preferences \ Code Editors \ Code Insight". Мой вольный перевод возможно сбивает с истинных шагов бага, поскольку словосочетание "when the Code Insight window is opened when a huge script is loaded" можно двояко понять: процессы открытия помощника кода и загрузки файла происходят одновременно, либо помощник кода срабатывает для уже имеющегося в редакторе текста большого размера. Поскольку первый вариант, по-моему, не реален для воспроизведения, то тестировать буду лишь второй случай. Но ни одна из моих гипотез не дала результата, поэтому предполагаю, что причина бага не только в сочетании размера скрипта и работающего помощника. Возможно где-то пересеклась работа с деревом кода или иным модулем. Так что пункту RNs не могу дать ни балла.
Datasets 0 из 1 возможного
• Fixed the ability to view data of the referenced object type.
Исправлена возможность просмотра данных объектного типа.
По аналогии с ранее проверенным фиксом в рамках SQL Editor ищем разницу в отображении данных объектной таблицы и таблицы с объектными полями. К сожалению, никаких отличий с предыдущим билдом не позволяют мне дать ни балла за фикс.
Итого по билду: 1.2+3.5=4.7 баллов из 3+14=17 возможных дают 4.7/17=28% готовности, которая снижается на -3.1 балла за счёт выявленных багов.
IMPROVEMENTS 0+0.5+0.7=1.2 из 3 возможных, -1-0.8-1-0.3=-3.1 за баги
Preferences 0 из 1 возможного, -1 за баги
• Removed the “Notify about AMS expiration” check box from the License Key page.
Убран чек-бокс для предупреждения об окончании периода оказания сервиса поддержки со страницы лицензионного ключа.
Структура RNs подразумевает блок удалений, но этот пункт оказался в группе новшеств. Поэтому, кроме проверок по чит-листу для опций, необходимо протестировать систему AMS, то есть поискать изменения в лицензионном соглашении или в других источниках на предмет оказания техподдержки. Примечание: убранная опция имела иное наименование в режиме ограниченной по времени версии (в нашем обычном случае - триал). С интерфейсной точки зрения новшество, а вернее - удаление, выполнено. Поскольку хелп не менялся с 28/11/2019, то в нём до сих пор имеется инфа про возможность сократить спам. К тому же, в хелп-топике "Preferences – License Key" всё ещё нет описания давно появившейся кнопки "Update License.." на странице лицензионного ключа настроек приложения. Функционально напоминания переместились из самостоятельного окна трея в панель системных предупреждений, о чём ни слова не сказано в RNs и хелпе. Никак не могу сказать, что это новшество чем-то улучшило работу пользователя с приложением, поскольку юзер теперь не может управлять спамом. Стоит пояснить, что предупреждения появляются автоматически при каждом старте приложения с увеличивающейся регулярностью при приближении даты очередного платежа: за месяц, за неделю, за 5-4-3-2-1 дней. В случае многопользовательской лицензии админа продукта затерроризируют пользователи без выхода в инет своим неравнодушием и предупредительностью. Во избежание именного этого раздражения изначально и была введена эта опция. Поэтому описанное новшество считаю именно ухудшением, а не улучшением. Если бы QA вовремя вмешался в планирование фиксов, то это ухудшение не было бы внедрено. Поэтому пункт RNs не получает вроде бы заслуженный балл (сделано во вред юзеру) и к тому же теряет ещё балл за неполноценность исполнения (текст RNs ограничен одним случаем и не упомянут функциональный перенос, хелп не актуализирован).
Нотификации об окончании периодов тех.поддержки не единственные перенесены в системную панель. Код модуля OSD обрабатывает всё, связанное с тех.поддержкой, видимо поэтому и конфирмация о сохранении (полагаю, и об отправке) OSD-сообщения перенесена из самостоятельного диалога в панель системных предупреждений. Об этом изменении функционала не упомянуто в RNs, да вдобавок оно принуждает пользователя к дополнительным переживаниям (подтверждение не входит в рабочую область приложения, а значит теряется из области видимости) и телодвижениям (системная панель - это соседнее окно, которое нужно активировать отдельно от работающего приложения). Скрытые переделки такого рода вынуждают снимать баллы с билда: -0.5 за само изменение функционала и -0.3 за не оповещение юзера.
Session Navigator 0.5 из 1 возможного, -0.5-0.5=-1 за баги
• Added all missing fields to the Process tab and the most frequently used ones are now displayed by default.
Добавлены все забытые поля на страницу процессов и более востребованные теперь отображаются по-умолчанию.
Подразумеваю, что данное новшество зависит от версии базы данных. Скорее всего в Oracle 12-ой версии и более последних добавились параметры отслеживания сессионных процессов. К сожалению, тех.писательница этого не упомянула. Искать дополнительно подсказки в хелпе бесполезно, потому что он давно (с ноября 2019г.) не актуализирован. Видимо совмещение тех.писательницей функций маркетолога (именно она спамила потенциальных покупателей) не позволяет ей управляться с двумя должностями одновременно. Полноценно проверить новшество у меня нет возможности по двум причинам: 1) до сих пор работоспособность модулей Session Navigator и Top Session Locator не приведена в надлежащий вид из-за проблемы при перекодировке юзера системы (запрос "select osuser from v$session" для всех системных сессий возвращает иероглифы, при том что для сессий приложения отрабатывает благополучно); 2) нет баз Oracle различных версий. Но список полей даже в модуле без данных сравнить с предыдущей версией SD вполне доступно: к ранее имевшимся двенадцати полям добавились ещё тринадцать, но не из системного вьювера процессов, а из системного вьювера сессий и может ещё какого-то (отследить запрос не удаётся из-за бага с системным юзером).
 |
| Добавленные параметры в числе дефолтных |
В процессе локализации бага "partial multibyte character" обнаружилась проблема с настройкой тулбара для области SQL History в окне SQL Editor. Это не новый баг текущего билда. Его появление зависит от каких-то изменений в модуле Icon Dictionary, поскольку теперь тулбар истории запросов абсолютно невозможно настроить - любой клик в IDic оставляет на тулбаре истории запросов редактора лишь одну кнопку копирования текущего текста в новую закладку редактора. Это серьёзный интерфейсный баг для SQL Editor из-за отсутствия обходных путей, поэтому билд теряет ещё -0.5 балла.
Code Editor 0.7 из 1 возможного, -0.3 за баги
• All occurrences of selected text are now highlighted in the Code Editor.
Все случаи выбранного текста теперь подсвечиваются в редакторе кода.
Очень странная формулировка новшества, из которой абсолютно не понятно о каких выборках текста идёт речь. На ум приходит только функция поиска по тексту, либо подсвечивание имён объектов при работе "Ctrl+Click". Если бы тех.писательница более тщательно подбирала термины из общепринятого глоссария, то вместо слова "selected" было бы "searching" и у меня не возникло бы никаких проблем с пониманием новшества. Интуиция меня не подвела, все искомые символы теперь подсвечиваются жёлтой подложкой сразу после позиционирования курсора на первом найденном. Тестирование осуществляем на любом своём тексте, набранном или вставленном в SynEdit (область редактора кода в SQL Editor, Stored Program Editor). В обычном текстовом редакторе (дополнительное окно для символьного поля в гриде данных) ничего подобного не приделано. Результаты моих исследований поиска в редакторе кода не утешительны. Новшество не доделано в двух направлениях: 1) настройки приложения не обрели новую опцию, то есть жёлтый цвет ни на что иное не сменить, что может быть опасно наложением и смешиванием раскраски; 2) первое найденное вхождение первоначально подсвечивается серым (по-умолчанию), а после перехода курсора на следующее вхождение (по F3) его подсветка обнуляется вместо замены на жёлтую подложку (ещё веселее случай поиска с середины кода). Если же поиск осуществляется в пределах предварительно выделенного (подсвеченного) текста, то подсветка последующих найденных вхождений отрабатывает достаточно логично. В процессе тестирования поиска в рамках выделенного текста выяснились баги: 1) при достижении предела текущего направления поиска больше не предлагается возобновить его с первоначально искомой позиции; 2) смена направления поиска при достижении предела в рамках выделенного текста всё ещё предлагает возобновить поиск с исходной позиции, но при этом границы поиска обнуляются: нет расцветки, исходная позиция приравнивается к началу/концу всего кода. За усовершенствование могу дать лишь 0.7 балла и за баги сниму 0.3 балла.
BUGS FIXED 0.5+1+0+1+0+1+0+0=3.5 из 2+5+1+2+1+1+1+1=14 возможных
Core 0.5+0=0.5 из 2 возможных
• Fixed the error “Could not initialize taskbar. Error:-2147467263” when running SQLDetective on Windows Server with Citrix.
Исправлена ошибка инициализации таскбара при запуске приложения на специализированной системе.
Это фикс бага из числа CustDev (индивидуальная разработка). Вероятно, какой-то перспективный покупатель пренебрёг системными ограничениями, описанными в ReadMe, инсталляционном мастере и на сайте компании ConquestSS, где указаны лишь конкретные операционные системы. Указанная в баге вариация платформы не является распространённой, поэтому фикс авансом примем на веру, перенаправив его проверку конкретному пользователю, зарегистрировавшему проблему. За такие индивидуальные правки можно получить не более 0.5 балла.
• Files in UTF-8 (with no BOM) and UTF-16 are now imported and analyzed correctly.
Файлы определённого сочетания юникодности теперь импортируются и анализируются правильно.
Текстовка бага ограничивает тесты особыми форматами текстовых файлов, путает понимание наличием терминов "импорт", "анализ" и "правильно". О каком импорте в данном случае идёт речь? Импорт данных в соответствующем мастере или открытие текстового файла в редакторе кода? Анализ кода в редакторе имеется ввиду или анализ объекта базы по командам ALTER, ANALYZE? Какие конкретно правила теперь учитываются и для каких действий и условий, если опираться в тестах на термин "правильно"? Ни один из вопросов не проясняется за счёт причисления пункта RNs к блоку Core. Такая размытая формулировка даёт мне право не включать фикс в билд. Чтобы не выявить массу дополнительных багов, как несоответствие термину "correctly", не буду проводить тесты гипотез. Поэтому только 0 баллов.
Примечание: если вам сильно захочется помучаться и поискать фикс, то тестовые данные - файлы - создавайте изначально в независимом стабильном приложении - Блокнот OS Windows. Символы можно набирать через альтернативный ввод: удерживая ALT набрать трёх-пятизначный ASCII-код символа. Внимательно выбирайте юникодные параметры сохранения файла, которые доступны в ниспадающем списке диалога сохранения файла.
SQL Editor 0+0.5+0.5+0+0=1 из 5 возможных
• The SQL Editor no longer hangs if the script execution is suspended after an error.
Редактор больше не зависает, если исполнение скрипта отсрочено после ошибки.
Для проведения тестирования необходимо удостовериться, что модуль настроен должным образом. Для этого откроем страницу "Preferences \ Code Editors \ SQL Editor" в установках приложения и проверим статусы опций "Prompt to break execution for all statements" (диалог позволяет обрабатывать исполнение скриптов в ручном режиме) и "Suspend script execution on error" (включенный режим откладывает выполнение после ошибки автоматически). В предыдущих билдах исполнение любого скрипта, даже без ошибок, подвешивало окно процесса исполнения после второго-третьего запуска скрипта. В текущем билде этот диалог не мозолит глаза, но после его исчезновения всё окно SQL Editor теряет всяческое управление: на тулбаре нет ни одной рабочей кнопки, закладки не реагируют на клики мышью, контекстное меню не появляется даже по нажатию функциональной клавиши на клавиатуре, лишь некоторые глобальные экшены доступны по горячим клавишам (поиск "Ctrl+F" не срабатывает, но запуск скрипта "Ctrl+Enter" или обновление данных "F12" происходит). Благо, закрытие окна доступно без проблем и дополнительных средств. В отличие от предыдущего билда, диалоговое окно процесса переименовано в авто-детектирование плана исполнения, но набор интерфейсных элементов остался прежним. Так что могу заключить, что фикс не решает проблему. Программист что-то изменил, но никакой ощутимой пользы юзеру не предоставил. Поэтому пункт RNs не получает ни балла.
• Removed the limit on the number of characters in a single line.
Убран лимит на количество символов в одной строке.
В предыдущем билде в редакторе кода (SQL Editor, Stored Program Editor), окне для вывода результатов запроса "SQL Editor / SQL Output" и текстовом редакторе (дополнительное окно для просмотра и ввода значений в символьные поля модуля SmartDataset) количество символов одной строки ограничивалось 1024 или 255 позициями. Но, если в редактируемые области ещё можно было вставить из буфера не ограниченное количество, то вывод значений запроса почему-то был обойдён вниманием программиста. Поправили возможность набивать символы в одну строку более 1024 символов, но строки в SQL Output окне и даже при spool-команде в файл всё-ещё обрезаются после 255 знаков. Этот баг выяснился мной в процессе подготовки статей о юбилярах по годам, поэтому пришлось воспользоваться не удобствами SD, а надёжностью SQL*Plus, который не обрезает, а всего лишь переносит длинные строки.
 |
| Установки вывода результатов запроса |
• Fixed the splitter positioning on maximizing/restoring the window.
Зафиксировано позиционирование разделителя при максимизации и восстановлении окна.
Интерфейс SQL Editor имеет пять сплиттеров в разных местах: между редактором и закладками для отображения результатов, в двух закладках с результатами, между деревом кода и редактором, между историей запросов и редактором. О каком из них речь в данном пункте? Это придётся выяснять в исследовательских тестах. А чтобы выявить уровень регрессии к вариантам сворачивания и максимизации окна следует добавить его закрытие/открытие в режимах максимизации и средней величины, а также статус свёрнутости межсплиттерных панелей.
| Легенда: | |
|---|---|
| 1 | между редактором и закладками для отображения результатов |
| 2 | на закладке Data Output |
| 3 | на закладке статистики |
| 4 | между деревом кода и редактором |
| 5 | между историей запросов и редактором |
| вариации \ сплиттеры | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| размер раскрытых панелей | |||||
| из среднего в максимизированный | без изменений | без изменений | без изменений | без изменений | увеличивается |
| из максимального в средний | без изменений | без изменений | без изменений | без изменений | уменьшается |
| закрытие и открытие среднего | без изменений | без изменений | без изменений | без изменений | без изменений |
| закрытие и открытие максимизированного | без изменений | без изменений | без изменений | без изменений | без изменений |
| закрытие среднего, открытие максим. | без изменений | без изменений | без изменений | без изменений | увеличивается |
| закрытие максим., открытие среднего | без изменений | без изменений | без изменений | без изменений | уменьшается |
| состояние прижатых панелей | |||||
| из среднего в максимизированный | оба направления учитывают тулбар | без изменений | без изменений | без изменений | без изменений |
| из максимального в средний | оба направления учитывают тулбар | без изменений | без изменений | без изменений | без изменений |
| закрытие и открытие среднего | оба направления учитывают тулбар | без изменений | без изменений | без изменений | без изменений |
| закрытие и открытие максимизированного | оба направления учитывают тулбар | без изменений | без изменений | без изменений | без изменений |
| закрытие среднего, открытие максим. | оба направления учитывают тулбар | без изменений | без изменений | без изменений | без изменений |
| закрытие максим., открытие среднего | оба направления учитывают тулбар | без изменений | без изменений | без изменений | без изменений |
• Fixed the ability to view data of the referenced object type.
Поправлена возможность просмотра данных ссылочных объектных типов.
Если вы хорошо знакомы со структурой объектов базы данных Oracle и возможностями приложения SD, то интуиция может вывести вас, как и меня, на таблицу с объектными полями, либо на объектную таблицу, два типа запросов из которой выполнены в закладку Data Output. Первый тип запроса - прямое перечисление полей, а второй - через спецсимвол звёздочки "select * from". Для теста нам нужны будут две таблицы на основе объектных типов: вся таблица и лишь некоторые поля. Пример возьмём из документации по базе данных Oracle.
-- создаём объектный тип "obj1" с двумя атрибутами "fld1" и "fld2"
CREATE TYPE obj1 AS OBJECT (fld1 VARCHAR2(100), fld2 NUMBER)
NOT FINAL;
/
-- создаём объектную таблицу "obj_tbl" на основе объектного типа "obj1"
CREATE TABLE obj_tbl OF obj1;
/
-- создаём таблицу "obj_fld_tbl" с полем "obj_fld " на основе объектного типа "obj1"
CREATE TABLE obj_fld_tbl (tb_fld number, obj_fld obj1);
/
Для обеих таблиц генерим (перетаскивание объекта из дерева Object Navigator предлагает тексты запросов "Select *" и "Select All") в SQL Editor запросы двух типов. Грид таблицы "obj_tbl" в обоих случаях состоит из двух столбцов, а гриды таблицы "obj_fld_tbl" состоят из двух и трёх столбцов для запросов "Select *" и "Select All" соответственно, как в предыдущем, так и в текущем билдах. Для каждого поля при необходимости открывается дополнительный редактор соответствующего типа (калькулятор, текстовый редактор или грид ссылочных полей). В этом плане между билдами тоже нет никакой разницы, из чего заключаем, что либо никакого фикса не сделано, либо тех.писателю было объяснено исправление программистом не точно, либо у тех.писательницы не хватило знаний для конкретизации фикса в рамках текста RNs. Отсутствие изменений даёт мне право на нулевой балл.
• Fixed parsing of the quotes in the SQL*Plus comments (REM).
Исправлено вычленение кавычек в комментариях SQL*Plus.
SQL Editor предназначен для исполнения не только команд SQL, но и специфичных для SQL*Plus действий. Комментарий в скрипте может быть трёх типов: однострочный после двойного минуса или REM символов, многострочный в окружении слешей и звёздочек. Кавычки в коде могут быть одинарными, двойными и альтернативными. Поскольку в RNs не указан тип кавычек, то исследуем изменения в билде для всех трёх типов, но альтернативные глянем лишь одной вариации, чтобы не превращать тесты в бесконечность. Хотя вполне возможны баги в каких-то не указанных вариациях. Для достоверности тестов будем использовать одинаковые кавычки в закомментированной и исполняемой части скрипта. Обращать внимание стоит на графическое (цветовое) отображение текста в редакторе (интерфейсный компонент SynEdit) и результат от исполнения скрипта (на закладке SQL Output), поскольку тех.писательница не указала предмет применения парсера.
 |
| Срабатывание комментариев при исполнении скрипта |
Stored Program Editor 0 из 1 возможного
• An access violation error no longer occurs on the stored program execution.
Ошибка доступа больше не случается при исполнении хранимой программы.
Поскольку не конкретизирован тип исполняемой программы и причины ошибки, то попытаемся воспроизвести баг на любом объекте. И поскольку предыдущий билд исполняет благополучно первую попавшуюся мне процедуру, то этот мнимый фикс получает звание приписки и не даёт билду ни балла.
Session Navigator 0.5+0.5=1 из 2 возможных
• The error ‘’‘is not a valid integer value.’ no longer occurs when there are no results to show in the filtered Session Navigator.
Ошибка инвалидного целого значения больше не случается, когда в отфильтрованном навигаторе сессий нет результатов для отображения.
К сожалению, навигатор сессий не работает с базой из-за проблемы с системным юзером. А не имея иных машин для тестирования проверить фикс не могу. Авансом на веру дам 0.5 балла.
• Fixed the ability to kill database sessions in the RAC instance.
Исправлена возможность убивать сессии базы с распределённым доступом.
На моём тестовом стенде не только не работает модуль навигатора сессий, но и нет базы с распределённым доступом. Поэтому авансом на веру дам 0.5 балла.
Database Connection 0 из 1 возможного
• An access violation error no longer occurs on trying to connect to a new database after the previous connection was lost.
Ошибка доступа больше не случается при попытке коннекта к новой базе после потери предыдущего коннекта.
В данном случае необходимо определиться в понятиях "новый коннект" и "потеря предыдущего". Поскольку основное окно коннекта к базе имеет список последних коннектов, то предполагаю, что "новым" коннект должен быть для этого списка, то есть надо подключаться либо юзером, либо именем базы, либо её типом, не имеющим аналогичное сочетание в списке предыдущих коннектов. Потеря коннекта может быть разных видов: физическая - отключение рабочего компьютера от сети/сервера с базой, логическая - убивание или отсоединение сессии средствами администратора базы. Важным моментом надо считать текущий модуль приложения, выявивший потерю сеанса, и работоспособность мониторинга коннекта через настройку "Preferences \ General \ Session \ Keep connection alive - png DB every [NN] seconds". Также не лишней будет гипотеза о превышении граничных значений: 1) окно коннекта имеет опцию в 20 сохранений по-умолчанию предыдущих удачных коннектов; 2) SD можно настроить на разрешение только одной сессии базы в рамках запущенного приложения "Preferences \ General \ Session \ Only one connection per SQLDetective instance". Ещё одним аспектом тестирования этого фикса можно считать наличие в приложении простого окна коннекта к базе, которое можно вызвать командой connect в SQL Editor. Какой из пяти вариантов давал ошибку в прошлом билде? Придётся искать тестировщику, потому что тех.писательница поленилась уточнить условия, то есть актуализировать баг. Мне не удалось воспроизвести баг в прошлом билде по догадкам, поэтому пункт RNs остаётся без баллов.
Database Connection Options 1 из 1 возможного
• The error that is shown on trying to add a new database connection type with the existing connection type name is no longer handled by EurekaLog.
Ошибка, которая показывается при попытке добавить новый тип коннекта к базе с существующим именем типа коннекта больше не отслеживается утилитой EurekaLog.
Тех.писательница в попытке конкретизировать баг наворотила текст, который вполне можно было уместить в меньшее количество словарных оборотов: добавление дубликата типа коннекта обрабатывается как внутренняя ошибка приложения вместо общесистемной. Стоит пояснить, что внешняя утилита EurekaLog отслеживает большинство ошибок приложения и некоторые проблемы базы, формируя системные логи. Если юзер сам добавил дубликат в число типов коннектов, то это не может быть ошибкой системы и должно обрабатываться интерфейсом приложения. Описанная обработка существовала в SD прежних версий, до перехода программистов на современный компилятор DelphiXE. Для воспроизведения в предыдущем билде откройте окно опций коннекта из окна последних коннектов, в блоке Database Type кликните по кнопке с плюсиком и введите наименование, аналогичное видимому в комбобоксе, после клика по кнопке подтверждения оцените окно и текст ошибки. Этому регресс-багу уже пятый год. Полагаю, что его отыскали в закромах BTS и включили в билд лишь для массовости правок, потому что у подобной мелочёвки обычно очень низкая важность. Но, тем не менее, он приносит целый балл.
Code Insight 0 из 1 возможного
• The exception “Object lock not owned.” no longer occurs when the Code Insight window is opened when a huge script is loaded in the SQL Editor or Stored Program Editor.
Исключение об отсутствии владельца блокированного объекта больше не срабатывает, когда окно помощника кода открыто для огромного скрипта, открытого в редакторах кода.
Для воспроизведения бага в прошлом билде вам придётся самостоятельно определить огромность скрипта, исходя из системных возможностей вашего компа. Для некоторых тестовых стендов несколько лет назад губительным был размер в два мегабайта, для иных - в десять мегабайт или 500 килобайт. Реальные юзеры присылали в тех.поддержку тела пакетов в сотни тысяч строк, так что можете начать с простой дублированной процедуры. Перед открытием файла в редакторе убедитесь, что подсказчик кода сработает автоматически, для чего достаточно установить настройки по-умолчанию на странице "Preferences \ Code Editors \ Code Insight". Мой вольный перевод возможно сбивает с истинных шагов бага, поскольку словосочетание "when the Code Insight window is opened when a huge script is loaded" можно двояко понять: процессы открытия помощника кода и загрузки файла происходят одновременно, либо помощник кода срабатывает для уже имеющегося в редакторе текста большого размера. Поскольку первый вариант, по-моему, не реален для воспроизведения, то тестировать буду лишь второй случай. Но ни одна из моих гипотез не дала результата, поэтому предполагаю, что причина бага не только в сочетании размера скрипта и работающего помощника. Возможно где-то пересеклась работа с деревом кода или иным модулем. Так что пункту RNs не могу дать ни балла.
Datasets 0 из 1 возможного
• Fixed the ability to view data of the referenced object type.
Исправлена возможность просмотра данных объектного типа.
По аналогии с ранее проверенным фиксом в рамках SQL Editor ищем разницу в отображении данных объектной таблицы и таблицы с объектными полями. К сожалению, никаких отличий с предыдущим билдом не позволяют мне дать ни балла за фикс.
Итого по билду: 1.2+3.5=4.7 баллов из 3+14=17 возможных дают 4.7/17=28% готовности, которая снижается на -3.1 балла за счёт выявленных багов.
Комментариев нет:
Отправить комментарий