|
|
|
Сравнение компонентов для доступа к данным
|
|||
|---|---|---|---|
|
#18+
zladeyka, Вообще-то у юнидаковских датасетов есть вкладка "Data Type Mapping", где можно указать, какого именно типа поля возвращаются в запросе -- как раз на случай, если их анализатор сам справится не может. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2015, 20:31 |
|
||
|
Сравнение компонентов для доступа к данным
|
|||
|---|---|---|---|
|
#18+
ZeroMQА для чего вы вообще на новую версию переходили? Ну вот у вас есть "огромнейший проект", все в нем работает, известные проблемы обойдены теми или иными способами. Вы решили дернуть удачу за хвост? Как я уже писал в своем предыдущем посте, иногда нам приходится урезать какую-то часть своего функционала, если UniDAC содержит такие ошибки, где собственными силами исправить их не представляется возможным. В это новой версии эти баги были исправлены и мы решили обновить версию, дабы обратно включить часть нашего функционала. Впоследствии, нам пришлось откатиться обратно на предыдущую версию UniDAC 6.2.8, т.к. лучше урезать часть своих функций, чем вообще испортить клиентские учетные БД неверными числами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2015, 20:41 |
|
||
|
Сравнение компонентов для доступа к данным
|
|||
|---|---|---|---|
|
#18+
zladeykaZeroMQА для чего вы вообще на новую версию переходили? Ну вот у вас есть "огромнейший проект", все в нем работает, известные проблемы обойдены теми или иными способами. Вы решили дернуть удачу за хвост? Как я уже писал в своем предыдущем посте, иногда нам приходится урезать какую-то часть своего функционала, если UniDAC содержит такие ошибки, где собственными силами исправить их не представляется возможным. В это новой версии эти баги были исправлены и мы решили обновить версию, дабы обратно включить часть нашего функционала. Впоследствии, нам пришлось откатиться обратно на предыдущую версию UniDAC 6.2.8, т.к. лучше урезать часть своих функций, чем вообще испортить клиентские учетные БД неверными числами. Ну, любой опыт - он положительный. Мы вот уже много лет используем одну из последних версий FIB+ 6.9. Точно так же пару раз нарывались на грабли, когда "просто так" переходили на новые версии. И версию Delphi меняем очень нечасто, по той же причине. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2015, 20:50 |
|
||
|
Сравнение компонентов для доступа к данным
|
|||
|---|---|---|---|
|
#18+
А я вот недавно (недели две назад) обновил VirtualTreeView с версии 5.0.0 на 6.2.1. Уже 7 или 8 правок пришлось внести. Где-то на 5й правке сильно задумался, может вернуть всё взад? Но сейчас вроде работает стабильно, местами чуть быстрее.. Конечно это не сравнить с проблемами доступа к данным, но для себя отметил, что действительно не стоит торопиться с обновлениями того, что и так работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2015, 12:37 |
|
||
|
Сравнение компонентов для доступа к данным
|
|||
|---|---|---|---|
|
#18+
zladeyka UniDAC для работы с большими таблицами > 300к записей не годится - потребляет очень много памяти. Их новая фича "SmartFetch" призвана это дело побороть, но вот уже сколько билдов подряд, начиная с версии 5.3 её не могут довести до ума. Постоянно AV-шки, assert'ы на равном месте (то при удалении\изменении записи, то на RAISERROR в триггере MS SQL UniDAC валится стопкой AV-шек). Эти баги правят, но на это зачастую уходят месяцы от релиза до релиза. В новом билде эти ошибки исправлены, но с ним приходит и стопка новых багов. Написать какой-то мало-мальски серьезный коммерческий продукт становится невозможным. Сейчас у меня версия 8.0.1. И снова проблема. Есть запрос с макросом Код: sql 1. 2. 3. 4. 5. 6. 7. Включаем SmartFetch. В коде указываем текст макроса: Код: pascal 1. 2. 3. 4. Получаем Project raised exception class EIBCError with message 'Dynamic SQL Error SQL error code = -204 Ambiguous field name between table TYPES and table TABLE1 ID'. При этом UniQuery1.FinalSQL выдает рабочий код, который в IBExpert нормально отрабатывает: Код: sql 1. 2. 3. 4. 5. 6. 7. Если отключить SmartFetch, код работает нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.02.2020, 17:41 |
|
||
|
Сравнение компонентов для доступа к данным
|
|||
|---|---|---|---|
|
#18+
X11 Если отключить SmartFetch, код работает нормально. Значит, SmartFetch как-то меняет значение FinalSQL. Лови то, что на сервер уходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.02.2020, 18:02 |
|
||
|
Сравнение компонентов для доступа к данным
|
|||
|---|---|---|---|
|
#18+
Я вообще до конца не понимаю, что такое SmartFetch и с чем его едят? Соответственно, не понимаю, а нужно ли мне оно вообще? Например, если у меня 1000 или 10000 записей в таблице, откуда выполняется Select? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.02.2020, 18:47 |
|
||
|
Сравнение компонентов для доступа к данным
|
|||
|---|---|---|---|
|
#18+
X11, там строится свой запрос, исключающий загрузку больших полей, вроде фактически грузятся лишь ключевые поля. Ну и генератор запросов налажал. Например, у тебя в табличке есть поле FK c именем вроде ИМЯFKТАБЛИЧКИ_ID, а генератор создал алиас с таким же именем для поля PK ключа, ну вот тебе и "аmbiguous field name between", панимаш... Ну ты посмотри в отадчике, что на самом деле, в точке иксцепшна - интересно же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.02.2020, 19:28 |
|
||
|
Сравнение компонентов для доступа к данным
|
|||
|---|---|---|---|
|
#18+
X11, При открытии таблицы в режиме SmartFetch, считываются только значения ключевых полей и полей указанных в свойстве PrefetchedFields для всех записей, возвращаемых запросом. После открытия таблицы, происходит чтение полей для количества строк, указанных в свойстве FetchRows. Остальные поля будут прочтены непосредственно при обращении к ним. Эффективность работы SmartFetch при извлечении любых данных таблицы зависит от используемых в этой таблице типов полей. Наибольший прирост производительности наблюдается при использовании SmartFetch для типов данных с большими значениями, таких как long string, BLOB, и т.д. При использовании SmartFetch режима UniDAC, если свойство TUniQuery.SmartFetch.SQLGetKeyValues установлено в пустую строку, UniDAC пытается составить и выполнить запрос на чтение ключевых полей и полей указанных в свойстве PrefetchedFields. Когда SQL запрос является сложным, как в вашем случае, автоматически сгенерированный запрос может быть некорректным. В таком случае вам следует в свойстве TUniQuery.SmartFetch.SQLGetKeyValues.Text указать запрос на получения полей, которые будут уникально идентифицировать запись. Например: Код: pascal 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2020, 16:56 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=39932553&tid=2038532]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
52ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 359ms |

| 0 / 0 |
