Вы можете вызвать метод TUniQuery.Conditions.Enable без указанной вами проверки.Akella писал(а): ↑Сб 29 фев 2020 16:06 Не смог найти в справке и в документации некоторые ответы на мои вопрос. Например, как правильно использовать UniQuery.Conditions.Enable/Disable у функционала условий.
Не до конца понятно: если несколько раз добавляешь условия, то нужно ли перед этим вызывать Disable?
Достаточно ли просто того, что я вызову UniQuery.Conditions.Enable перед UniQuery.Open? Или обязательно/желательно выполнить такую проверку:UniQuery.Conditions.Enable нужно вызывать только после построения всех условий и перед Open или Conditions.Enable нужно/можно вызывать перед началом добавления условий?UniQuery.Conditions.Count > 0 then
UniQuery.Conditions.Enable;
Найдено 212 результатов
- Вт 03 мар 2020 15:41
- Форум: Universal Data Access Components
- Тема: Как ПРАВИЛЬНО работать с Conditions.Enable/Disable?
- Ответы: 3
- Просмотры: 8801
Re: Как ПРАВИЛЬНО работать с Conditions.Enable/Disable?
- Вт 03 мар 2020 15:39
- Форум: Universal Data Access Components
- Тема: пропадает значение параметра после Conditions.Add
- Ответы: 5
- Просмотры: 9574
Re: пропадает значение параметра после Conditions.Add
Спасибо за информацию мы воcпроизвели проблему со сбросом значения параметра, используемого в TDACondition при добавлении нового TDACondition, и постараемся исправить его в следующем билде. Как временное решение вы можете использовать следующие рекомендации:Akella писал(а): ↑Чт 27 фев 2020 14:29 Delphi Tokyo, UniDAC 8.0.1.
В UniQuery добавлено 2 условия и 2 параметра. Потом нужно закрыть датасет, добавить ещё одно условие (без параметров) и снова открыть. Проблема в том, что сразу после добавления нового условия, т.е. после "UniQuery1.Conditions.Add" пропадает значение одного параметров, при этом имена параметров/условий не пересекаются (т.е. разные).
сделал такой пример.вот 4 снимка, на них видна хронологияКод: Выделить всё
procedure SetCondVal(uniQuery: TuniQuery; const Name, Val: string); Var Cond: TDACondition; q: integer; n, v: string; begin Cond := uniQuery.Conditions.Find(Name); // здесь значение параметра (LCDMIN) ещё на месте for q := 0 to pred(uniQuery.ParamCount) do begin n := uniQuery.Params[q].Name; v := uniQuery.Params[q].AsString; v := v;// для бряки end; if Assigned(Cond) then begin Cond.Value := Val; Cond.Enable; end else uniQuery.Conditions.Add(Name, Val, True);// это условие выполняется // здесь значение параметра (LCDMIN) уже потерялось for q := 0 to pred(uniQuery.ParamCount) do begin n := uniQuery.Params[q].Name; v := uniQuery.Params[q].AsString; v := v;// для бряки end; end;
http://prntscr.com/r8hrbx
http://prntscr.com/r8hs9s
http://prntscr.com/r8hskj
http://prntscr.com/r8hstg
Может это поможет решить проблему.
Параметр "TYPESIDS" добавлен с помощью макроса, а проблемный параметр "LCDMIN" добавлен с помощью Conditions.Add().
Я не выполняю ни Conditions.Disable, ни Conditions.Clear, просто сразу добавляю новое условие.
По идее, параметр не должен терять свое значение. Сам параметр же не теряется.
- добавить все TDACondition;
- вызвать метод TDAConditions.Enable для возможности установить значения параметров используемых в TDACondition;
- установить значения для всех параметров;
- вызвать метод TUniQuery.Open.
- Пн 02 мар 2020 14:58
- Форум: Universal Data Access Components
- Тема: пропадает значение параметра после Conditions.Add
- Ответы: 5
- Просмотры: 9574
Re: пропадает значение параметра после Conditions.Add
При открытии таблицы в режиме SmartFetch, считываются только значения ключевых полей и полей указанных в свойстве PrefetchedFields для всех записей, возвращаемых запросом. После открытия таблицы, происходит чтение полей для количества строк, указанных в свойстве FetchRows. Остальные поля будут прочтены непосредственно при обращении к ним.Akella писал(а): ↑Сб 29 фев 2020 08:54 Пока создавал тестовый проект, появилась ещё одна проблема после того, как я заменил текст макроса.
И эта ошибка происходит, если включено свойство SmartFetch.
Project raised exception class EIBCError with message 'Dynamic SQL Error
SQL error code = -204
Ambiguous field name between table TYPES and table TABLE1
ID'.Тестовый проект я отправлю со страницы ContactForm.Код: Выделить всё
procedure TForm1.Button1Click(Sender: TObject); Var i: integer; begin UniConnection1.Connect; UniQuery1.close; UniQuery1.Conditions.Clear; UniQuery1.MacroByName('TYPES').Value := 'LEFT JOIN TYPES T ON T.ID = A.ID_TYPE AND T.USERNAME = :USERNAME'; UniQuery1.ParamByName('USERNAME').AsString := 'user'; UniQuery1.open;<<< ошибка при открытии UniQuery1.close; UniQuery1.Conditions.Add('tname', 'T.NAME = :TNAME', True); UniQuery1.Conditions.Enable; UniQuery1.ParamByName('TNAME').AsString := 'qqqq'; UniQuery1.Conditions.Add('tname', 'T.ID > 10', True); Memo1.Lines.Add(UniQuery1.FinalSQL); UniQuery1.open; Memo1.Lines.Add(UniQuery1.FinalSQL); Memo1.Lines.Add(''); Memo1.Lines.Add('params'); for I := 0 to pred(UniQuery1.Params.Count) do Memo1.Lines.Add(UniQuery1.Params[i].Name + ' = ' + UniQuery1.Params[i].AsString); end;
Я забыл добавить, что база для Firebird 3 (UTF8).
Запрос, который выдает FinalSQL, вполне нормальный и в IBExpert ID он выполняется без ошибокКод: Выделить всё
SELECT A.ID, A.NAME NAME_USER, A.REMARK FROM TABLE1 A LEFT JOIN TYPES T ON T.ID = A.ID_TYPE AND T.USERNAME = :USERNAME
Эффективность работы SmartFetch при извлечении любых данных таблицы зависит от используемых в этой таблице типов полей.
Наибольший прирост производительности наблюдается при использовании SmartFetch для типов данных с большими значениями, таких как long string, BLOB, и т.д.
При использовании SmartFetch режима UniDAC, если свойство TUniQuery.SmartFetch.SQLGetKeyValues установлено в пустую строку, UniDAC пытается составить и выполнить запрос на чтение ключевых полей и полей указанных в свойстве PrefetchedFields.
Когда SQL запрос является сложным, как в вашем случае, автоматически сгенерированный запрос может быть некорректным. В таком случае вам следует в свойстве TUniQuery.SmartFetch.SQLGetKeyValues.Text указать запрос на получения полей, которые будут уникально идентифицировать запись. Например:
Код: Выделить всё
SELECT
A.ID
FROM TABLE1 A
LEFT JOIN TYPES T ON T.ID = A.ID_TYPE AND T.USERNAME = :USERNAME
- Пт 28 фев 2020 12:54
- Форум: Universal Data Access Components
- Тема: пропадает значение параметра после Conditions.Add
- Ответы: 5
- Просмотры: 9574
Re: пропадает значение параметра после Conditions.Add
Для более быстрого и полного ответа, пожалуйста, составьте и вышлите нам, с помощью контактной формы https://www.devart.com/company/contactform.html, небольшой пример демонстрирующий указаное вами поведение, включающий необходимые скрапты на создание объектов БдД и укажите точную версию вашего MySQL сервера.
- Чт 26 сен 2019 12:17
- Форум: Oracle Data Access Components
- Тема: ODAC 11.0.1 and TOraSession TimeZone +2:00 forced
- Ответы: 5
- Просмотры: 12118
Re: ODAC 11.0.1 and TOraSession TimeZone +2:00 forced
При установки TIME_ZONE не учитывается отсутствие перехода на летнее\зимнее время в Direct режиме для данной TIME_ZONE. Мы исправили данное поведение ODAC, данное исправление войдет в следующий билд ODAC.
- Ср 25 сен 2019 12:46
- Форум: Oracle Data Access Components
- Тема: ODAC 11.0.1 and TOraSession TimeZone +2:00 forced
- Ответы: 5
- Просмотры: 12118
Re: ODAC 11.0.1 and TOraSession TimeZone +2:00 forced
Спасибо за информацию. Мы исследуем данное поведение ODAC и сообщим вам о результате. Пожалуйста, укажите TIME_ZONE установленную на клиенте.
- Вт 24 сен 2019 14:39
- Форум: Oracle Data Access Components
- Тема: ODAC 11.0.1 and TOraSession TimeZone +2:00 forced
- Ответы: 5
- Просмотры: 12118
Re: ODAC 11.0.1 and TOraSession TimeZone +2:00 forced
По умолчанию устанавливается TIME_ZONE клиента, а не сервера. Вы нашли корректное решения вашей задачи, так как конструкция ALTER SESSION SET TIME_ZONE служит для того, чтобы переустановить значение TIME_ZONE.
- Пт 30 авг 2019 13:06
- Форум: Universal Data Access Components
- Тема: Как правильно работать с транзакциями
- Ответы: 19
- Просмотры: 29925
Re: Как правильно работать с транзакциями
Пожалуйста, укажите точную СУБД с которой вы работаете.
- Пт 12 июл 2019 11:54
- Форум: Universal Data Access Components
- Тема: Как правильно отключаться от базы и завершать работу приложения?
- Ответы: 21
- Просмотры: 27869
Re: Как правильно отключаться от базы и завершать работу приложения?
Если Вы хотите, чтобы мы добавили указанную вами функциональность, пожалуйста, напишите об этом на нашем User Voice форуме: https://devart.uservoice.com/forums/104 ... y_id=18939. Если Ваше предложение наберет достаточно голосов, мы рассмотрим возможность его создания.
- Пт 12 июл 2019 11:33
- Форум: Universal Data Access Components
- Тема: Как правильно отключаться от базы и завершать работу приложения?
- Ответы: 21
- Просмотры: 27869
Re: Как правильно отключаться от базы и завершать работу приложения?
Это стандартное поведение наших компонентов и оно не предусматривает отключение.
- Пт 12 июл 2019 06:40
- Форум: Universal Data Access Components
- Тема: Как правильно отключаться от базы и завершать работу приложения?
- Ответы: 21
- Просмотры: 27869
Re: Как правильно отключаться от базы и завершать работу приложения?
Да вы правы, мы писали вам об этом неоднократно.
- Пт 12 июл 2019 06:27
- Форум: Universal Data Access Components
- Тема: AutoCommit у TUniQuery не работает
- Ответы: 3
- Просмотры: 9995
Re: AutoCommit у TUniQuery не работает
Свойство SpecificOption будет содержать название и значение опций, которые имеют значения отличные от дефолтных, как в дизайнтайеме так и в рантайме.
- Пт 12 июл 2019 05:40
- Форум: Universal Data Access Components
- Тема: Как правильно отключаться от базы и завершать работу приложения?
- Ответы: 21
- Просмотры: 27869
Re: Как правильно отключаться от базы и завершать работу приложения?
Как мы писали ранее, Firebird требует активной транзакции для любой операции с данными. Поэтому UniDAС автоматически стартует транзакцию при выполнении операции с данными.
- Ср 10 июл 2019 14:10
- Форум: Universal Data Access Components
- Тема: AutoCommit у TUniQuery не работает
- Ответы: 3
- Просмотры: 9995
Re: AutoCommit у TUniQuery не работает
У свойства TUniConnection.AutoCommit более высокий приоритет, чем у опции "AutoCommit" для наборов данных(TUniQuery, TUniTable). Если свойство TUniConnection.AutoCommit имеет значение False, транзакции могут быть совершены только явно (несмотря на значение опции "AutoCommit" для наборов данных).
Если бы хотите совершать транзакции автоматически для большинства наборов данных, а для отдельных наборов данных - вручную, установите значение True для свойства TUniConnection.AutoCommit. Для ручного управлениях транзакциями, установите значение False для опции "AutoCommit" для нужных наборов данных.
Если бы хотите совершать транзакции автоматически для большинства наборов данных, а для отдельных наборов данных - вручную, установите значение True для свойства TUniConnection.AutoCommit. Для ручного управлениях транзакциями, установите значение False для опции "AutoCommit" для нужных наборов данных.
- Ср 10 июл 2019 07:41
- Форум: Universal Data Access Components
- Тема: Как правильно отключаться от базы и завершать работу приложения?
- Ответы: 21
- Просмотры: 27869
Re: Как правильно отключаться от базы и завершать работу приложения?
Рады слышать, что проблема решена.
Компоненты UniDAC не содержпт свойтсв подобных Autostart transaction.
Обращайтесь к нам, если у Вас возникнут вопросы по UniDAC.
Компоненты UniDAC не содержпт свойтсв подобных Autostart transaction.
Обращайтесь к нам, если у Вас возникнут вопросы по UniDAC.