Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
Приветствую всех. База на SQL Server 2008 R2 Express Edition Пользователи через инет подключаются с удаленных мест к базе. Клиентская часть написана на VB6 с применением ADO, ComponentOne TrueDBGrid При слабом инете скорость работы с данными в Grid'е, вообще загрузка данных, даже обычный SELECT "не почеловечески виснет" (ForwardOnly, ReadOnly recordset) Как можно исправить ситуацию? Инет ускорить возможности нету, может быть есть другие компоненты доступа к данным? Заместо ADO, для более быстрой работы? Ммм... какой-нибудь собственный direct-connect или еще что Кстати, строка подключения Provider=SQLOLEDB;Data Source и т.д. Спасибо за внимание и надеюсь на помощь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2010, 18:30 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
Перегружать рекордсет локально (в массив или в локальный рекордсет) и использовать без постоянных запросов к базе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2010, 18:32 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
еще какой-нибудь вариант, кроме сохранения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2010, 18:36 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
> Автор: orunbek > еще какой-нибудь вариант, кроме сохранения трех-звенку, прием-передача архивируется(я использую zlib.dll) + то что посоветовал Shocker.Pro Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2010, 18:42 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
Пока остановился на этом варианте: возврат записей через ADODB.Command посмотрим что получится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2010, 19:06 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
Распределенную базу еще можно. Поставь в филиалы урезанные микро-базы, и раз в цать минут синхронизируй их с базой в главном офисе. Удаленные клиенты будут подключаться к своим локальным копиям. Тормоза интернета будут "спрятаны" под репликацией. Искать замену ADO - бессмысленно. Вот если б речь шла о медленной машине со быстрой сетью, и умением/возможностью работать с нативными интерфейсами (это означает выкидываешь VB, переходишь на C). Тогда переход с ADO был бы оправдан. Да и то вряд-ли. Оверхед у ADO конечно есть, но он настолько минимальный что пользователям он практически не заметен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2010, 19:08 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
что-нить подобное Direct Oracle Access для SQL-сервера нету? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2010, 19:14 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
Не надо пытаться показать в Grid-е весь миллион найденных записей. Используя SELECT TOP или соответствующее свойство Recordset-а нужно ограничить выборку несколькими десятками - для того чтобы продолжить поиск юзер пускай уточняет запрос, а не листает Recordset... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2010, 18:27 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
orunbekчто-нить подобное Direct Oracle Access для SQL-сервера нету?Конечно есть. TDS называется. Но если ты сумеешь на VB работать с ним быстрее чем через ADO - я тебе лично памятник поставлю с надписью "Самому быстрому извращенцу" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2010, 20:10 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
AndrFНе надо пытаться показать в Grid-е весь миллион найденных записей. Используя SELECT TOP или соответствующее свойство Recordset-а нужно ограничить выборку несколькими десятками - для того чтобы продолжить поиск юзер пускай уточняет запрос, а не листает Recordset... Миллион записей и не отображается, максимум 50 записей отображается, фильтр по дате и т.д. White Owlorunbekчто-нить подобное Direct Oracle Access для SQL-сервера нету?Конечно есть. TDS называется. Но если ты сумеешь на VB работать с ним быстрее чем через ADO - я тебе лично памятник поставлю с надписью "Самому быстрому извращенцу" :) Раз я это в теме VB написал, то соотвественно имел в виду компонент или способ быстрого доступа к базе SQL Server, который можно использовать именно в VB6 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 08:10 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
здесь написано: автор .... .... 1. System.Data.SqlClient Хотя этот инструмент не имеет оболочки пользовательского интерфейса (в отличие от других инструментов этого списка), он является новшеством для работы с базами данных SQL Server в Visual Studio.NET. Использование протокола Tabular Data Stream (TDS) классом System.Data.SqlClient в ADO.NET, в отличие от более ранних версий ADO использующих OLE DB, предоставляет возможность разработчикам задействовать более родное и самое быстрое подключение приложения к SQL Server по протоколу TDS. .... .... Значит если необходимо писать приложение в котором очень важен скорость доступа к данным, то лучше писать на VB.NET? С использованием System.Data.SqlClient ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 08:16 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
orunbek, совершеннейшее ИМХО. Если открываешь одно соединение, считываешь данные на клиента, закрываешь соединение, то каким бы ты способом это не делал, разницы для пользователя особо не будет. Основное время - передача по каналу данных, а накладные расходы (установка соединения, отправка запроса) мизерные. DataGrid же пытается открыть курсор на сервере, ездить по нему, держать и поддерживать открытое соединение. Вот тут и начинают накладные расходы превалировать над передачей данных. И переход с АДО на какую-то другую технологию без смены самого алгоритма проблему не решит, ну, допустим, получишь ускорение в 20% на накладных расходах. На скорость передачи данных это не повлияет (упираемся в канал) и на наличие этих постоянных накладных расходов - это проблема датагрида, а не технологии доступа. Все это можно посмотреть и оценить в профайлере. Так что лучше скачать данные на клиента, 50 записей - это не так уж много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 09:56 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
По поводу Grid'а, я знаю причину медленной работы, и в этом плане и не собираюсь решать проблему, в принципе устраивает Проблема была в том, что обычный SELECT * FROM Table WHERE ID=N работает очень медленно, иногда даже отваливается, параметры recordset'а ForwardOnly, ReadOnly Затем нашел другой способ получение результата через хранимку посредством ADODB.Command, в котором хранимка возвращает тот же SELECT * FROM Table WHERE ID=N, в этом случае случаев отваливания соединения или ошибки выполнения команды вразы меньше стало, и время возврата данных тоже увеличилось, о чём и писал в первых 2-3 сообщениях ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 10:10 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
Никакой разницы быть не должно. От ADO сервер получает команду на выполнения запроса или команду на выполнения процедуры и возвращает рекордсет. С точки зрения АДО ничего не меняется, по-разному обрабатывается это исключительно сервером. Предварительная компиляция (процедура) против динамического запроса при таком простом запросе видимого выигрыша не даст. P.S. Вам точно звездочка в запросе нужна? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 10:16 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
SELECT * FROM это я так написал, здесь на форуме в реале идет выборка полей, попробовал через recordset и через ADODB.Command - хранимка возвращает recordset, разница есть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 13:01 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
Посмотрите здесь http://msdn.microsoft.com/en-us/library/aa224819(SQL.80).aspx ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 13:02 |
|
||
|
Альтернатива ADO для быстрой работы с базой при слабом инете
|
|||
|---|---|---|---|
|
#18+
orunbekПо поводу Grid'а, я знаю причину медленной работы, и в этом плане и не собираюсь решать проблему, в принципе устраивает Проблема была в том, что обычный SELECT * FROM Table WHERE ID=N работает очень медленно, иногда даже отваливается, параметры recordset'а ForwardOnly, ReadOnly Может еще поигратся с другими параметрами Recordset? 1) CacheSize установить попробовать (по умолчанию 1), например 100 2) rs.Open ... adAsyncExecute 3) CursorLocation = adUseClient ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2010, 08:50 |
|
||
|
|

start [/forum/topic.php?fid=60&fpage=120&tid=2159454]: |
0ms |
get settings: |
11ms |
get forum list: |
11ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 388ms |

| 0 / 0 |
