Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
Интересно работает связка MSSQL+Access! При открытии таблицы производится выборка не всей таблицы целиком, а только малый кусочек, который отображается в текущий момент на экране. Механизм примерно следующий: вначале выбирается только ключевое поле таблицы ID. затем подготавливается запрос для выборки нескольких полей с помощью недокументированной процедуры sp_prepexec после этого при скроллинге в процедуру sp_execute передаЁтся следующая партия выбранных из таблицы ИД... Делфевый Query считывает ВСЮ таблицу, что существенно медленнее, и кроме того Акцессовый способ позволяет видеть на 99% актуальные данные, т.е. для этого не нужно делать Requery. Вопрос такой: возможно ли реализовать подобный механизм на Delphi или может кто уже реализовал, помогите советом или ссылкой плиз! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2003, 13:49 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
Делфевый Query считывает ВСЮ таблицу... Дельфофый Query считывает то, что ты попросил. Если ты там написал SELECT * FROM TableWithMillionsRecords, то почему это должно быть быстро? кроме того Акцессовый способ позволяет видеть на 99% актуальные данные А вот тут на счет актуальности можно посоприть, что считать актуальностью. Если ты в гриде увидел 20 записей, прокрутил вниз на следующие 20 записей, и потом снова прокрутил вверх, то при таком подходе, как работает Access ты можешь увидеть в перво двадцатке совершенно другие данные. Кроме то, постоянные перезапросы к серверу при каждом скроллинге - это ни есть хорошо для архитектуры клиент\сервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2003, 13:58 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
В общем-то никто не запрещает в дельфовых запросах самому писать нужные sp_execute. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2003, 14:04 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
Но ведь если я в Акцессе делаю SELECT * FROM TableWithMillionsRecords, то он мне ведь моментально открывает первую порцию. Проблема в том что есть информационная база в которой много записей, и куча приложений обращаются к элементам этого справочника (грубо говоря делаю лукаповые поля). Соответственно при загрузке прога долго думает, и много памяти жрет, что тоже не есть хорошо :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2003, 14:08 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
> Dankov Дык ведь это все ручками надо, а я человек избалованный ВЭЦЭЭЛем :), вот я и спрашиваю может уже есть какой отработанный механизм для этого ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2003, 14:09 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
Проблема в том что есть информационная база в которой много записей, и куча приложений обращаются к элементам этого справочника (грубо говоря делаю лукаповые поля). Ну так не делают лукап поля на больших справочниках!!! А если у решь пошла о Query. То TQuery при работе с сиквелом не тащит сразу все данные на клиента, а делает выборку при необходимости из открытого серверного курсора, что приводит к повисанию разделяемой блокировки. Поэтому в своих клиентских прогах, работающих через BDE, я использовал доработанный TQuery. И одна из доработок заключалась в вызове FetchAll сразу после Open. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2003, 14:19 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
Ну так не делают лукап поля на больших справочниках!!! Не совсем понимаю почему нет. Оно конечно не такое лукаповое с треугольничком, а с эллипсисом и по элипсису открываю форму, в которой могу выбрать другой элемент справочника, с поиском там, все дела ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2003, 14:30 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
Ну так и пиши, что форма выбора, а то лукап поле. Но если это форма выбора, то обычно сначала пользователь должен задать критерии поиска и тока потом послать запрос к базе, а не гнать на локальную машину весь справочник и уже на клиенте искать. Представляю, какие бы моим клиентам машины понадобились, если б я все свои 80 000 записей из классификатора товаров и услуг гнал на клиента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2003, 14:33 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
возможно ли реализовать подобный механизм на Delphi или может кто уже реализовал, помогите советом или ссылкой плиз! можно использовать dbExpess TSQLQuery+TProvider+TClientDataSet У TClientDataSet`a есть проперть PacketRecords Механизм примерно следующий: вначале выбирается только ключевое поле таблицы ID. затем подготавливается запрос для выборки нескольких полей с помощью недокументированной процедуры sp_prepexec после этого при скроллинге в процедуру sp_execute передаЁтся следующая партия выбранных из таблицы ИД... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2003, 16:42 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
TADODataSet, св-во CacheSize не поможет? А вообще согласен с pkarklin - если в справочнике больше ~800-1000 записей, надо предварительно накладывать какой-то фильтр. Ибо реально никому такое кол-во записей в лукапе не нужно - потреб. юзеру запись в середине такой таблицы и будет он у тебя гонять по-акцесной технологии запросы туда-сюда ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2003, 16:53 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
SerjaTo. Интересно, а как Вам удалось получить ТАКОЙ метод работы MS SQL-Access? Я специально создал ADP, в нем приконнектился к Northwind. Создал форму для таблицы Orders И все в профилере было обычно - Select * from orders. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2003, 20:15 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
2 Cat2 Не, я создал просто mdb и через связь с данными приконнектился к MSSQL 2 pkarklin грубо говоря: есть таблица "использование кредита", отображаемая в главной форме. В ней есть поле "контрагент", которое как раз и берется из информационной БД. (Т.е. в таблице хранится его ИД :). Я делаю элипсовый лукап на это поле. Для того чтобы юзверь видел не пустые строчки в лукапе, приходится иметь запрос на ВСЮ таблицу контрагентов, а для выбора контрагента в форме выбора приходится иметь еще и параметризованный запрос для выбора контрагента. Вот такая вот фигня ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 06:48 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
Я делаю элипсовый лукап на это поле. Для того чтобы юзверь видел не пустые строчки в лукапе, приходится иметь запрос на ВСЮ таблицу контрагентов, а для выбора контрагента в форме выбора приходится иметь еще и параметризованный запрос для выбора контрагента. Вот такая вот фигня Фигня, конечно. Невижу я тут никаких лукап полей. Выводи юзеру в гриде набор из одного запроса, связанного со справочником контрагентов через INNER JOIN, а при выборе из формы Справочник контрагентов, прописывай ID и наименование контрагента, естественно, что в гриде поле с наименованием контрагента должно быть реадонли и с кнопочкой в конце... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 08:16 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
2 pkarklin А с добавлением проблем не возникнет если INNER JOIN юзать (я имею в виду если напрямую через грид добавлять или сие есть моветон)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 08:21 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
А... Тоды все понятно. Локальные СУБД в гетерогенных запросах тянут всю инфу из всех таблиц на клиента и там выполняют запросы. Наверное, MS чуть облегчило эту задачу и тянет через Jet только ключевые поля. Ваше счастье, что Ваши таблички не очень большие. На лимоне записей Ваши запросы умрут. Нельзя спрячь в одну телегу файл- и клиент-сервер.Если уж очень надо, то можно работать через MS SQL, а mdb подключать как Linked Server. Что ни в коей мере не противоречит постингам pkarklin. Он писал об однородной среде MS SQL. И надо с ней работать, используя его рекомендации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2003, 23:08 |
|
||
|
Увеличение скорости доступа к MSSQL
|
|||
|---|---|---|---|
|
#18+
А с добавлением проблем не возникнет если INNER JOIN юзать (я имею в виду если напрямую через грид добавлять или сие есть моветон)? А какие проблемы с добавлением, чет я не пойму? Ну добавили запись, заполнили нужные поля, какие непосредственно в гриде, какие путем выбора из форм справочников. Ведь после того, как мы получили набор на клиента, хоть с 30 десятками INNER JOINов, дальше мы могем с ним делать все, что нам заблагорассудиться. Естественно, что компоненты, обеспечивающие доступ к данным, должны давать возможность разработчику самому принимать решение, что и как делать с набором, а не додумывать за него, как это делает ADO. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2003, 08:40 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=32198769&tid=2117784]: |
0ms |
get settings: |
7ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
53ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 375ms |

| 0 / 0 |
