Gustav: Unsorted, или Записки DAX-дилетанта - II

[Gustav]

Я был не очень силен при работе с отрицаниями (!...) в критериях запроса, так как до недавнего времени их практически не использовал. И хотя мне казалось, что там не должно быть ничего сложного, при первой же близкой встрече с ними я попал в ловушку.

Я представлял себе, чисто визуально, бубня что-то школьное типа "от перестановки мест слагаемых...", что запятая есть разделитель списка в строке критериев и далее, как ты их не перечисли, результат будет один и тот же. Поэтому для таблицы, содержащей числовое поле (ЧП) и 100 строк со значением этого ЧП от 1 до 100, я написал такой критерий:

PHP код:

!15,!19,11..20 


и ожидал получить в выборке 8 чисел от 11 до 20 без 15 и 19. Каково же было мое удивление, когда в выборке явились все 100 строк таблицы!

Желаемого результата удалось достичь после перестановки компонентов критерия:

PHP код:

11..20,!15,!19 


Объяснения наблюдаемого явления нашлись в "Библиотеке" у mazzy в замечательной статье "Поиск данных" ( http://axapta.mazzy.ru/lib/search/ ). Там есть такая скромная фраза: «Я не обновлял эту статью, поскольку в Microsoft Axapta 3.0 написан хороший хелп по поиску. Нажмите F1 когда указываете критерии в запросе, получите описание. Там все хорошо описано.». Однако, в «минуту жизни трудную» помогла именно статья, а не хелп. Точнее – дополнение к статье Андрея Бобкова:

Цитата:

«3. , (запятая) это символ, позволяющий объединить несколько критериев. Причем, если после запятой идет ! (восклицательный знак - отрицание), то запятая интерепретируется как логическое "И" (по смыслу получается "кроме"), а если нет отрицания - то как логическое "ИЛИ".»

Ознакомившись с этим важным знанием, я расписал свои критерии а-ля SQL и всё достаточно наглядно прояснилось:

PHP код:

!15,!19,11..20 --> (NOT (ЧП=15)) AND (NOT (ЧП=19)) OR (ЧП BETWEEN 11 AND 20)

11..20,!15,!19 --> (ЧП BETWEEN 11 AND 20) AND (NOT (ЧП=15)) AND (NOT (ЧП=19)) 


Здесь помним, что в Аксапте операции AND и OR имеют равные приоритеты (Логические операции в Х++) и выполняются последовательно слева направо. Хотя в данном случае это, возможно, лишнее замечание, так как в первом условии AND и так стоит левее OR (на самом внешнем скобочном уровне).

В хелпе же всё гораздо туманнее. Про запятую написано: "...соответствует нескольким критериям. Введите все критерии, разделив их запятыми." (я и вводил так!). И далее: "Например, "A..D, !C" находит "A", "B" и "D". Справедливости ради надо отметить, что, тем не менее, пример A..D,!C удачен (возможно, сам того не ведая ), так как сначала указан диапазон, а затем исключение.

Возможно, так и надо сформулировать правило для конечного пользователя: если для поля указывается несколько критериев через запятую, то критерии отрицания (исключения) следует указывать в конце строки после всех "неотрицательных" критериев.

Ну, и на сладкое – курьез из ДевГайда (по меню хелп-файла: Creating Queries => Query Basic => Organization of queries; или из MSDN: http://msdn.microsoft.com/en-us/library/bb278121.aspx) с критерием, нашему новоиспеченому правилу не соответствующим:

Цитата:

Ranges

A number of ranges can be defined for each data source. Each range is defined through the Value property. The Value property is a string that describes conditions to be met by the records in the data source. For example, if restrictions are required on which AccountNumbers the query should retrieve, the range defined would be:

"..5000, 5012 .. 5014, 5500, !6500, 6000.."

This line tell the system to retrieve:

* records with AccountNumbers less than or equal to 5000

* records in the range from 5012 to 5014, the record with the AccountNumber equal to 5500,

* records with AccountNumbers above 6000, except for the record with the AccountNumber equal to 6500

Утверждение «except for the record with the AccountNumber equal to 6500» ложно и значение 6500 присутствует в выборке (по уже выясненным выше причинам).


P.S. Интересно, что данный топик из DevGuide перед публикацией на msdn явно подвергался правке: например, заметно переработана таблица спецсимволов, используемых при построении критериев, а перед таблицей - фраза, которой очень не хватает в хелпе и которую я познавал по частям в разное время и из разных источников:

Цитата:

Range expressions on different fields are combined by using the AND expression.
Range expressions on the same field are combined by using the OR expression.

Критерий же примера так пока и не исправлен: ..5000, 5012..5014, 5500, !6500, 6000..


P.S. 14.04.2010. Имеется важная дополнительная информация в теме: Отличия операторов ! и != в фильтрах.

[Gustav]

История берет свое начало здесь: Создание нескольких экземпляров Excel. Там же указаны некоторые практические шаги по задачам, упоминаемым здесь.

Итак, в очередной раз столкнулся с этой "миной": разработчики (из весьма уважаемой компании, вроде пора бы уж... ан, увы!) использовали файл с расширением XLS (т.е. обычный файл Excel) в качестве шаблона для одного из наших отчетов. По закону подлости "заряд" сработал в напряженную пору конца года, когда этот отчет понадобился многим пользователям и повалились ошибки из-за монопольного захвата шаблонного файла.

Не препарируя код Аксапты, администратор настроил в Excel общий доступ для файла. Захваты прекратились, но появилось ненужное стандартное диалоговое окно с запросом имени сохраняемого файла. При этом по умолчанию имя предлагается с "единичкой" на конце: <ИсходноеИмяФайла>1.xls - т.е. как и в случае создания нового файла от шаблона XLT, за одним исключением - при порождении от XLT не требуется сиюминутного ввода имени нового файла.

Интересно, что сохранять файл в ответ на ненужное окно совсем не обязательно, т.е. можно нажать Cancel - при этом в памяти остается несохраненный файл с именем по умолчанию. Не знаю, считать эту "фичу" Excel "багой" или нет, но, по крайней мере, знать о такой особенности поведения надо. Пользователя же это лишнее ненужное окно, разумеется, раздражает вне зависимости от степени его осведомленности в этих тонкостях. Для наглядной демонстрации того, о чем идет речь, можно выполнить в окне отладки Excel такую команду: Application.Workbooks.Add("<полное имя файла, которому дан общий доступ>.XLS") и всё увидеть своими глазами.


Напрашивающиеся возможные сценарии использования "шаблона" XLS в подобных ситуациях выглядят следующим образом:

1. Невидимое для пользователя открытие шаблонного XLS-файла (командой Workbooks.Open(<имя файла>.xls)), программное копирование из него шаблонного листа в новый файл, закрытие шаблонного XLS-файла, дальнейшая работа с новым файлом. Несмотря на быстрые автоматические операции, все равно возможны конфликты пользователей в борьбе за файл (без общего доступа).

2. Открытие XLS-файла без общего доступа как шаблона (командой Workbooks.Add(<имя файла>.xls)), сохранение под новым именем. В промежутке между открытием и сохранением другие пользователи не могут воспользоваться файлом. Практика показала, что конфликты успевают возникнуть даже при быстром программном сохранении файла под именем, ранее запрошенным у пользователя (как дополнительное неудобство такого программного варианта - обязательность сохранения файла на диске).

3. Открытие XLS-файла с общим доступом как шаблона (командой Workbooks.Add(<имя файла>.xls)), борьба с ненужным окном, сохранение под новым именем. Тем не менее, постоянный свободный доступ других пользователей к файлу.


Эти три сценария приведены для того, чтобы обрисовать примерный алгоритм борьбы с проблемами, возникающими из-за использования файла XLS в качестве шаблона:

* Если вы настроили общий доступ к файлу и проблемы прекратились (пользователи не конфликтуют и лишнее окно не появляется), то, скорее всего, используется сценарий 1 и ваши проблемы на этом закончились (в код лезть не придется).

* Если же после настройки общего доступа появилось лишнее окно, то вы, вероятно, перешли от сценария 2 к сценарию 3. Вам следует при помощи Excel переделать файл XLS в XLT (не просто изменив одну букву в расширении, а сохранить файл как шаблон) и внести необходимые изменения в код X++ (здесь уже просто заменив одно расширение файла на другое).

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


Всего этого можно избежать, если выработать в себе самом и распространять среди других привычку с самого начала работать с нормальными шаблонами - файлами с расширением XLT.

Ну, или работать в своей Аксапте одному в одной сессии - тоже способ избежать блокировок со стороны других пользователей. С Наступающим!

[Gustav]

Столкнулся со следующими проблемами при создании наследника RunBaseBatch дублированием (копированием) из другого класса-наследника (работаю с Ax 3.0 SP4):

1) невозможность отобразить вкладку "Пакет" - бездействие метода canGoBatch;
2) невозможность откомпилировать новый класс - ошибка в методе main с сообщением "Нельзя создать объект, поскольку абстрактный метод RunBase.pack() не реализован."

По первой проблеме нашёл рекомендацию здесь: Замена стандартной формы Dialog. Не выводится вкладка Пакет. . Действительно, заработало после того, как создал класс не просто дублированием другого класса, а создал новый класс вручную и перетащил по очереди методы мышкой из исходного класса.

Вторая ситуация описана в теме: Ошибка в "Тренинге по Средствам Разработки" , но явный метод борьбы не указан. Поэтому изложу свой.

Как и из-за чего именно возникает проблема 2 по ходу дублирования (копирования) не заметил, но научился вопроизводить так:

* Контекстной командой Дублировать создадим копию класса Tutorial_RunBaseBatch - CopyOfTutorial_RunBaseBatch.
* Изменим метод main, подогнав его под новый класс:

static void main(Args args)
{
    CopyOfTutorial_RunbaseBatch    tutorial_RunBase;
;
    tutorial_RunBase = new CopyOfTutorial_RunbaseBatch();

    if (tutorial_RunBase.prompt())
        tutorial_RunBase.run();
}

Всё хорошо, всё компилируется и выполняется.

* Переименуем метод pack, например, в mypack. Компиляция теперь проходит неудачно и указывает на метод main c выдачей упомянутого выше сообщения.
* Возвращаем методу pack его прежнее имя pack. Компиляция в ответ не становится удачной и информирует о той же ошибке.

И вот то, что помогло: комментируем в main строку c new, компиляция - ОК, далее раскомментируем строку и опять компилируем - ОК.

А самый первый раз наугад поборолся с проблемой 2 так: удалил метод main, скомпилировал класс без него и создал метод заново вручную.