|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Добрый день! Делаю программку в одной из форм использую MSHFlexGrid. Программа состоит из двух частей: 1) для удаленных клиентов, имеющая свою базу (хранилище mdb). 2) для центрального офиса (хранилище реализовано на mssql) и там и там MSHFlexGrid имеет источником данных recordset Для клиентской части сделан запрос заполняющий MSHFlexGrid. вот в части для центрального офиса возниклb заминки 1) тот же самый запрос (сохраненный ввиде хранимки) отрабатывает в разы медленнее. С учетом наличия всего сотни записей успеваю досчитать до 10. На mdb хранилище открывается мгновенно. Пробовал и кодом и в хранимке делать, время выполнения одинаково. 2) проблема с отображением даты, при чем опять же на SQL хранилище. в этом же запросе (для mdb) с помощью команды FORMAT преобразую дату к тому виду, который мне нужен. С SQL этот номер не проходит. Я помню что на самом SQL было преобразование даты, вот только редко с sql базами общаюсь забыл :( Запрос Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 09:05 |
|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Alex_men1) тот же самый запрос (сохраненный ввиде хранимки) отрабатывает в разы медленнее. Надо смотреть план запроса, добавлять индексы, оптимизировать план и т.п. Лучше это делать в ветке MSSQL. Сотня записей ВО ВСЕХ используемых таблицах? Не верю в 10 секунд! Скорее всего, в какой-то из связанных таблиц записей много, а план построился неоптимально. Время каждый раз одинаковое или разное? Может проблемы с блокировками если база интенсивно используется? попробуйте WITH (NOLOCK) Alex_men2) проблема с отображением даты, при чем опять же на SQL хранилище. в этом же запросе (для mdb) с помощью команды FORMAT преобразую дату к тому виду, который мне нужен. С SQL этот номер не проходит. Я помню что на самом SQL было преобразование даты, вот только редко с sql базами общаюсь забыл :( CONVERT ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 09:43 |
|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Кстати, очень неплохо бы в INNER JOIN вынести условие объединения, а не отдаваться на волю WHERE. Вот где скорее всего проблема. Если объединить без условий три таблицы по 100 записей, то результатом объединения будет 1000000 записей. Они потом, конечно, отберутся с помощью where, но поначалу оптимизатор может сработать и не оптимально, особенно если нет нужных индексов. Так что в первую очередь прописывай условие объединения в where, потом остальное, но скорее всего это решит проблему. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 09:48 |
|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Shocker.ProНадо смотреть план запроса, добавлять индексы, оптимизировать план и т.п. Лучше это делать в ветке MSSQL. Пойду там посмотрю. Shocker.ProСотня записей ВО ВСЕХ используемых таблицах? Не верю в 10 секунд! Скорее всего, в какой-то из связанных таблиц записей много, а план построился неоптимально. Да верно две таблицы имеют по 10000 записей Shocker.ProВремя каждый раз одинаковое или разное? Может проблемы с блокировками если база интенсивно используется? попробуйте WITH (NOLOCK) время всегда одинаковое. А база и прога еще на стадии разработки Shocker.ProCONVERT это имеется ввиду? но ведь это преобразование типов данных, а не формата отображения CONVERT ( data_type [ ( length ) ] , expression [ , style ] ) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 10:04 |
|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Alex_menПойду там посмотрю. Начни с переписывания INNER Alex_menДа верно две таблицы имеют по 10000 записей Ну так, а ты их еще перемножаешь, вот и получается 100000000 записей только из двух таблиц Alex_menвремя всегда одинаковое. тогда не блокировки Alex_menэто имеется ввиду? но ведь это преобразование типов данных, а не формата отображения CONVERT ( data_type [ ( length ) ] , expression [ , style ] ) А хелп по Convert слабо почитать? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 10:10 |
|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Shocker.ProКстати, очень неплохо бы в INNER JOIN вынести условие объединения, а не отдаваться на волю WHERE. Вот где скорее всего проблема. Если объединить без условий три таблицы по 100 записей, то результатом объединения будет 1000000 записей. Они потом, конечно, отберутся с помощью where, но поначалу оптимизатор может сработать и не оптимально, особенно если нет нужных индексов. Так что в первую очередь прописывай условие объединения в where, потом остальное, но скорее всего это решит проблему. К сожалению у меня маловато опыта, и я честно говоря не представляю как в иннер внести условие отбора записей. Использовать подзапросы и объединять уже их результат? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 10:15 |
|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Alex_menК сожалению у меня маловато опыта, и я честно говоря не представляю как в иннер внести условие отбора записей. Использовать подзапросы и объединять уже их результат? а, блин, я не обратил внимания, что ON там все же, не сталкивался с таким синтаксисом попробуй раскрыть скобки, правда теперь не уверен, что это поможет: Код: plaintext 1. 2. 3.
скорее всего дело в отсутствии индексов на полях, по которым идет объединение ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 10:27 |
|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Забавно, как только вставил преобразование CONVERT скорость выполнения возросла. Хотя по моему мнению должна была бы упасть, т.к. действий больше выполняется. Ладушки будем ковырять запрос пока не оптимизируется. Если будут какие предложения Буду весьма благодарен. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 10:36 |
|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Alex_menЗабавно, как только вставил преобразование CONVERT скорость выполнения возросла. Хотя по моему мнению должна была бы упасть, т.к. действий больше выполняется. Ладушки будем ковырять запрос пока не оптимизируется. Если будут какие предложения Буду весьма благодарен. А куда ты его вставил-то? Скорость выполнения зависит от того, какой план запроса составит оптимизатор. В 95% случаев он составляет его оптимально. Если ты чуть переделал запрос - оптимизатор мог составить другой план и скорость возрасти именно из-за этого, а не из-за самого CONVERT ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 10:40 |
|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Shocker.ProА куда ты его вставил-то? Да в том то и дело, что на скорость повлиять не должно. Вначале идет представление на SQL Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
а потом в коде выполняю запрос Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 11:02 |
|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Alex_menсохраненный ввиде хранимки Alex_menВначале идет представление на SQL это не одно и то же когда ты делаешь запрос к представлению, план составлется заново для совокупности твоего запроса из ВБ+самого представления. То есть фактически ты используешь ПОДЗАПРОС. Если сделать хранимку, план будет составлен заранее, его проще будет отладить, так что по возможности предлагаю перейти на хранимку. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 11:44 |
|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Спасибо попробую ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 12:14 |
|
Проблемы с MSHFlexGrid
|
|||
---|---|---|---|
#18+
Shocker.Pro, На самом деле так сделано было ради универсальности. Т.е. запрос источник используется один (большой запрос) а к нему идет множество фильтрующих запросов. Т.е. Могу задавать фильтр в любом разрезе. С хранимками - надо делать много хранимок. Вот из этих соображений так и Делалость ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2011, 12:26 |
|
|
start [/forum/topic.php?fid=60&msg=37244717&tid=2158747]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
43ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 159ms |
0 / 0 |