Хочу выводить деталь проекта только для определенного условия
if ((Dataset.Values('EssenceType') == 'Work') &&
(Dataset.Values('TypeID') == '{1142CDEE-FA70-4CB6-8DBC-20C7F68B71BB}') &&
(Dataset.Values('OfferingTypeID') == '{FCB4DC72-C668-46C8-8BFF-E6ABA7FD9411}')) {
...
выдает ошибку: Поле 'Тип' не активно
почему выскакивает такая ошибка? и как можно решить данную задачу?
Нравится
В sq_Project у колонки EssenceType поставьте флажок "Всегда выбирать в запросе"
EssenceType сравнивает без проблем, а вот поля TypeID и OfferingTypeID не хочет и ругается. как было указанно выше. Пробовал ставить флажок для этих двух полей в выборке, но не помогло.
"Штинов Антон Викторович" написал:
Запрос по проектам с юнионом идет. В юнионе тоже должна быть выбрана эта опция для указанных полей.
Лучше использовать GetFieldValueFromDisabledField(Dataset, FieldName).
"Раловец Ольга" написал:Лучше использовать GetFieldValueFromDisabledField(Dataset, FieldName).
Почему?
Таким образом Вы будете получать нужное значение только по требованию и избавите от необходимости выбирать данные из колонки, когда это не нужно, например, если детали скрыты. Или, если реестр проектов используется где-то отдельно вне раздела, то Вы и там будете в запросе всегда выбирать тип, а он там может быть ни к чему.
В этой ситуации лучше ставить галочку "Всегда выбирать в запросе". И вот почему
1. В приведенном примере Антон всегда при смене позиции в датасете будет анализировать эти поля
2. функция GetFieldValueFromDisabledField очень тяжела с точки зрения производительности. Если посмотреть на ее реализацию (к реализации вопросов нет, всё сделано корректно), то создается еще один датасет с уже активным нужным полем, и из которого уже берется значение. Получается что при смене позиции в датасете будет открыто еще три (для каждого не активного поля).
Так что наверно проще выбрать еще три поля чем на каждую запись делать еще три запроса.
Евгений, я думала об этом, но не знаю, как сравнить "тяжесть" передачи данных из трех лишних полей с сервера на клиент каждый раз при открытии набора данных и выполнение "тяжелых" операций на клиенте только при определенном запросе, но при условии, что запрос происходит часто. Не знаю, как сравнить количество открытий набора данных проектов без использования деталей с количеством переходов по записям при видимых деталях.
Для трех полей сразу GetDatasetFieldsValuesNamedArray(Dataset, FieldNames), а также при повторном обращении НЕ создается новый экземпляр набора данных, а sq кэшируется в атрибутах набора данных и переоткрывается.
Я просто встречал GetFieldValueFromDisabledField в функциях, которые используются ну очень часто, например раскраска реестра. И 1-2 ИДшника передать для 40 записей будет попроще, чем делать 40 доп.запросов на сервер.
Нужно быть очень осторожным с использованием этой функции.
"Раловец Ольга" написал:Для трех полей сразу GetDatasetFieldsValuesNamedArray(Dataset, FieldNames), а также при повторном обращении НЕ создается новый экземпляр набора данных, а sq кэшируется в атрибутах набора данных и переоткрывается.
Да, действительно есть такая функция, но все равно создается новый экземпляр Dataset
var Dataset = SelectQuery.Open();
Это на клиентской части. На сервере же, если данные выбираются в едином контексте (одним селектом) - то это проще для сервера, чем создавать отдельный контекст, отдельный курсор и т.д..... Хотя при очень сложных запросах нужно делать разные курсоры...
В общем для разных ситуаций используются разные подходы, и к сожелению, универсального подхода нет :smile:
"Глова Сергей" написал:Нужно быть очень осторожным с использованием этой функции.
Аватарка очень подходит к этой фразе :)
Евгений, ошибочно написала набор данных, имела ввиду сервис запроса.
Да, использование GetDatasetFieldsValuesNamedArray() каждый раз довольно ресурсозатратно, но и включение пары дополнительных полей в запрос повышает время его выполнения от нескольких десятков до сотни миллисекунд на моем примере в 130 записей.
"Раловец Ольга" написал:Глова Сергей пишет:Нужно быть очень осторожным с использованием этой функции.
Аватарка очень подходит к этой фразе :)
+1 :lol:
В общем, как сказал Евгений, использование зависит от ситуации