|
Медленное получение данных через TFDQuery (FireDAC)
|
|||
---|---|---|---|
#18+
vavan"мощно задвинул, внушает" (С) прошу назвать концептуальные отличия у разных серверов и клиентов в схеме prepare->execute->fetch. Или хотя бы execute->fetch. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2015, 13:37 |
|
Медленное получение данных через TFDQuery (FireDAC)
|
|||
---|---|---|---|
#18+
Valery_BТам скорее всего ADO.Net. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Скорее всего .Net SqlClient Data Provider ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2015, 13:58 |
|
Медленное получение данных через TFDQuery (FireDAC)
|
|||
---|---|---|---|
#18+
kdvпрошу назвать концептуальные отличия у разных серверовна столь высоком уровне концептуально они конечно все субд а на практике под капотом такого наверчено может быть что ожидать безусловного мгновенного отклика увы не приходится ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2015, 14:08 |
|
Медленное получение данных через TFDQuery (FireDAC)
|
|||
---|---|---|---|
#18+
vavan а на практике под капотом такого наверчено может быть про это я не говорю, и с этим не спорю, оптимизаторы у всех разные, но еще раз подчеркиваю, что самый простой запрос для тестирования скорости выборки, для всех СУБД выполняемый максимально быстро, это select * from table. Т.е. одна таблица, никаких условий отбора, группировок, сортировок, серверных курсоров и всего такого. Такой запрос готов выдавать записи за миллисекунды. А вот уже сколько времени будут выдаваться записи, зависит от многих факторов, включая сеть, если курсор серверный, компоненты, и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2015, 14:47 |
|
Медленное получение данных через TFDQuery (FireDAC)
|
|||
---|---|---|---|
#18+
Вообще деталей множество. Если в запросе блобы? У SSMS например по умолчанию все строки не более 256 символов в показе (не знаю хранит ли он полные строки). И.т.д. Записи он буферизирует - иначе бы грид для показа не прокручивался в обе стороны. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2015, 15:00 |
|
Медленное получение данных через TFDQuery (FireDAC)
|
|||
---|---|---|---|
#18+
Я правильно понял что автор сравнивает Код: pascal 1. 2.
и Код: pascal 1. 2.
Где 1-й последовательно выкачивает все 140 т.з, а второй 50 первых+50 последних? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2015, 19:46 |
|
Медленное получение данных через TFDQuery (FireDAC)
|
|||
---|---|---|---|
#18+
rgreatЯ правильно понял что автор сравнивает Код: pascal 1. 2.
и Код: pascal 1. 2.
Где 1-й последовательно выкачивает все 140 т.з, а второй 50 первых+50 последних? а с чего Last вычитывает именно 50 последних ? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2015, 21:26 |
|
Медленное получение данных через TFDQuery (FireDAC)
|
|||
---|---|---|---|
#18+
Последние 50 выкачивает только TFDTable в режиме LiveWindow. Там особая уличная магия. TFDQuery так не делает. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2015, 22:02 |
|
Медленное получение данных через TFDQuery (FireDAC)
|
|||
---|---|---|---|
#18+
Вот и я наткнулся на эту проблему в совсем ином разрезе. MSSQL, FireDac, D10.4.2, MS ODBC Driver 17. Проблема была fetch'е запросов по 1 записи, даже не содержащих блобов в середине Решилось так: 1 - тип курсора Forward Only. 2 - убрать в в исходниках выставление CUSROR_OPTIONS - Fast Forward Only - иначе принудительный серверный тип курсора (8) 3 - после закрытия стейтмента выставить ROW_ARRAY_SIZE = 1, в противном случае всё свалится опять в серверный курсор. Стейтмент открывается при ROW_ARRAY_SIZE = 1 и только потом, перед fetch выставляется правильный ROW_ARRAY_SIZE (это FireDac и так делает) В итоге чтение происходит порциями, указанными в FetchOptions а не всегда по 1. На VPN есть выигрыш. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2021, 22:50 |
|
|
start [/forum/topic.php?fid=58&gotonew=1&tid=2036956]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
57ms |
get topic data: |
9ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
others: | 236ms |
total: | 406ms |
0 / 0 |