Components for Delphi and C++ Builder.

Добрый день!

Lazarus 2.2.4, EhLib 11.0.10.

Копирую данные в MemTableEh примерно таким кодом:


Кодировка БД — UTF-8, СУБД — PostgreSQL 12. Если в исходном наборе данных есть строковое поле, то оно обрезается. То есть, для varchar(50) будет DataSet.Field.Size=50, MemTableEh.Field.Size=50, а строка обрежется до 50 байт, а не символов.

По-моему, это неправильное поведение компонента.
Подскажите, пожалуйста, можно поправить?


С уважением
Евгений.

Добрый день.

В документации по FPC - TFieldDefs.Add
https://www.freepascal.org/docs-html/fc ... s.add.html
нет точного определения понятия Size (Байты, Символы) для типа ftString.

Если считать, что TBufDataset это стандартный DataSet, который работает правильно.
То следующий код:



Дает результат 'АБ'

Значит, можно предположить, что Size задает размер в байтах.

_________________
Best regards
EhLib support Team

Всё так, в определении FieldDefs есть неопределённость. Однако в определении свойства Size типа TStringField указано чётко (выделено мной):
(https://www.freepascal.org/docs-html/fc ... .size.html)

Более того, компоненты доступа к серверам баз данных интерпретируют поле именно так, поэтому у меня и получилось, что в DataSet (непосредственно в этом месте TZQuery, но попробовал и со "стандартной" TSQLQuery) хранится полная строка, а в MemTableEh — нет.

Чуть позже проверю, как себя в этом отношении ведёт MemTableEh при подключении через TSQLDataDriverEh, хотя внутренний массив записей создаётся одинаково, скорее всего.

С уважением
Евгений.

А вот такое не подойдет?

procedure copyQryStructure(const mt: TMemTableEh; qry: TZquery);
var
i: integer;
begin
try
for i := 0 to qry.FieldCount - 1 do
begin
mt.FieldDefs.Add(qry.Fields[i].FieldName, qry.Fielddefs[i].DataType, qry.Fields[i].Size);
mt.FieldDefs[i].Attributes := qry.Fielddefs[i].Attributes;
mt.FieldDefs[i].Required := false; //Для версий выше 4.5.62
end;
mt.CreateDataSet;
mt.append;
mt.edit;
except
on e: exception do
begin
WriteToLog(progdir + 'error.log', datetimetostr(now) + ', Error № 10 ' + e.Message);
raise;
end;
end;
end;

procedure copyQryData(const mt: TMemTableEh; qry: TZquery);
var
i: integer;
begin
if not qry.IsEmpty then
try
screen.Cursor := crAppStart;
if not mt.Active then
mt.Active := true;
mt.First;
mt.Edit;
for i := 0 to qry.FieldCount - 1 do
begin
mt.Fields[i].Value := qry.Fields[i].Value;
end;
mt.Post;
screen.Cursor := crDefault;
except
on e: exception do
begin
screen.Cursor := crDefault;
WriteToLog(progdir + 'error.log', datetimetostr(now) + ', Error № 11B ' + e.Message);
raise;
end;
end;
end;

Так это то же самое получается.


Field.Size переносится корректно, проблема в интерпретации этого свойства. Например, родной TStringField при формировании размера блоков памяти делает так:

Пока подробно в коде EhLib не разбирался, а просто пошаговое выполнение не помогает, из-за захода в RTL (кстати, в Delphi, кажется, при пошаговом выполнении можно было в стандартные библиотеки заходить?), но, кажется, интерпретация Size как количества байт всё-таки в коде EhLib.


А это у меня отдельная процедура делает. Иногда просто нужно очистить обязательность полей в датасете.

С уважением
Евгений.

Приветствую!

К сожалению, поведение компонента при подключении через DataDriver точно такое же.
И если для "автономных" MemTable всё действительно довольно просто (установить размер строки самостоятельно при копировании структуры), то при работе через DataDriver обрезаются строки из БД и что с этим делать — непонятно.

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

С уважением
Евгений.

Переводите строки в WideString. Ниже напишу, как это сделать быстро.
У меня с UTF8 другая проблема - в AstraLinux - на большом объеме данных с текстовыми полями, серьёзно заполненными, при работе через MemTableEh периодически случаются вылеты при фильтрации или группировке данных в DBGridEh либо при переоткрытии набора данных (в т.ч. по установке фильтра на "базовый" источник данных - у меня ZTable и ZQuery). Под виндой всё нормально, кстати. А вот под openSUSE Leap 15.2 ошибка тоже воспроизвелась.
Судя по симптомам и месту, где вылетает ошибка, это в буферах MemTableEh некорректно выделяется память для значений строковых полей, и при копировании туда данных происходит выход за пределы выделенного сегмента. При этом если в датасете тип поля не StringField, а WideStringField, то ошибки не возникает: там используется другой механизм копирования данных (насколько я успел глянуть исходники).
Я так понимаю, что беда именно в UTF8 - переменное число байт на символ (от 1 до 4), откуда вытекает необходимость в исходнике ставить проверки на компиляцию под Linux и использовать специальные функции для работы с UTF8-строками (они есть).

Пока автор разбирается с указанными проблемами - предлагаю свои временные
РЕКОМЕНДАЦИИ ПО ОБХОДУ ПРОБЛЕМЫ
для тех, кто работает через ZeosLib: в ZConnection для свойства ControlsCodePage указываем cCP_UTF16 - и во всех связанных датасетах строковые поля автоматически будут создаваться как WideString.
Возможные траблы:
1. Если поля в датасетах созданы статически - надо пересоздать (в т.ч. в связанные MemTableEh, если используются).
2. Поля типа text из Memo преобразуются в WideMemo - и тут уже "ломается" MemTableEh, но в новой сборке автор обещал это поправить.
3. В DBGridEh надо обязательно включать опцию DrawMemoText, иначе вместо текста будем видеть "(MEMO)".
4. При работе в DBGridEh с нативной локальной фильтрацией "типа как в Excel" (выпадающие списки в титлах колонок, режим для работы через MemTableEh) - не дает поставить фильтр более чем на одну текстовую колонку. Решается путем написания собственной функции заполнения списка фильтрации и замыкании на нее событий FillSTFilterListValues для гридов. В принципе, ничего сложного там нет.

_________________
Старый опытный камикадзе...

Приветствую!


Насколько я понимаю, само хранение записи в памяти осуществляется как массив вариантов, по крайней мере, именно так определён TRecDataValues. Сильно в код не углублялся. Довольно странно выглядит разное поведение под Windows и Linux, возможно как раз реализация вариантов немного разная? Или в Линуксе UTF-16 по-умолчанию?

Спасибо! Выглядит вполне, правда, у меня получилось, что проще отказаться от работы через DataDriver. А вот включение DrawMemoText в гриде — дело при работе с Zeos обязательное, вне зависимости от ControlsCodePage. Дело в том, что, если я в запросе не произведу явное приведение типов для вычисляемой строки, Zeos посчитает это поле ftMemo. Например,

даст поле sample_string типа ftMemo, а

задаст полю тип ftString (при этом важно указать длину строки в SQL)

С уважением
Евгений

В Линуксе как раз по умолчанию UTF8, насколько я помню. Я глубоко в исходники тоже не закапывался - некогда, - но "опытным путем" пока удалось добиться приемлемого результата. Конечно, с учетом всех тех 4-х замечаний, которые я указал.

Это не только и не столько Zeos, это из PostgreSQL ноги растут - без явного приведения типа он для строковых функций делает результат типа "text", а не "varchar".

_________________
Старый опытный камикадзе...

Добрый день.

В сборку EhLib.VCL 11.0 Build 11.0.013 добавили исправление:
* Исправлено: В Lazarus при создании полей через FieldDefs не учитывается свойство TFieldDef.Codepage для строковых полей. В результате вместо CP_UTF8 создаются поля с кодом 0.

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

_________________
Best regards
EhLib support Team