Вход | Регистрация

Форумы на Кубань.Ру


1С:Предприятие ::

Метки: 

using ADO

Ø
Я
   asu
22.08.00 - 17:06
лагодаря своевременным советам MishGan-a, справился с ADO (по образцу Макслаба).
Теперь возник вопрос : каким образом инициализировать объект ADO - один раз при старте 1С или каждый раз при открытии формы (списка) справочника ?? У Макслаба инициализация объекта ADO стоит в ПриОткрытии() формы.
 
 
   maxlab
1 - 22.08.00 - 17:49
создай публичные переменные и инициализируй эту фишку в глобальном модуле...Может возникнуть проблема с коннектом, если он долгое время простаивает...Надо перед выполнением sql запроса проверять статус коннекта...Там метод есть специальный, правда я не помню как он называется
   Winter
2 - 22.08.00 - 18:32
Последжние пару дней тоже активно работал с ADODB, пришел к выводу что это тормоз ... По индексированным полям работает ещё ничего, а вот более сложные запросы эта штука оптимизировать не умеет.
Перешел на SQLMDO, эта вещь дествительно хорошая. Один и тот же запрос
SQLMDO выполняет раз в шесть семь быстрее чем ADODB. Если кого интересует более подробнее детали, могу выслать материалы по работе с SQLMDO. Хотя вся информация есть в help'e. Идёт она в поставке MS SQL 7.0, нужно только поставить клиента на станцию.
Вот несколько базовых методов для того кто захочет попробывать :
SQLDMOServer = CreateObject("SQLDMO.SQLServer");
SQLDMOServer.Connect(sql_server_name,sql_server_login,sql_server_psw);
QRes=SQLDMOServer.Databases(sql_database_name).ExecuteWithResults(sql_query);
Val=QRes.GetColumnString(Строка,Колонка)
SQLDMOServer.Databases(sql_database_name).ExecuteImmediate(sql_query);
SQLDMOServer.Close();
SQLDMOServer.BeginTransaction("TransactionSQLDMO");
SQLDMOServer.CommitTransaction("TransactionSQLDMO");
SQLDMOServer.RollbackTransaction("TransactionSQLDMO");
   maxlab
3 - 22.08.00 - 18:47
Ты хочешь сказать что, ради этого на все клиентские машины надо Desktop вариант SQL7.0 устанавливать? И вроде этот объект все равно OLEDB использует как мне кажется...
   Alex
4 - 22.08.00 - 19:09
    А какая разница, посредством какого инструмента передавать запросы и получать результирующие наборы данных, если обработка запроса все равно на сервере?
    Тем более maxlab прав - в конечном итоге все равно работа через OLEDB, только надстройки разные.
    Может дело в конструкции запроса? Или в том, что сервер накопил статистику по предыдущим запросам и оптимизировал на основании этого план выполнения запроса?
    А детали очень интересуют в связи с возможностью дальнейшего использования.
   maxlab
5 - 22.08.00 - 19:18
Меня, например, этот объект интересует в плане подготовки кубов для дальнейшего анализа...Бегло прочитав хелп, я понял что это возможно...но не ковырял пока :-)
   Alex
6 - 22.08.00 - 19:23
Кстати о кубиках. Есть ли опыт из создания и загрузки туда данных из 1С?
   Winter
7 - 22.08.00 - 21:06
>Desktop вариант SQL7.0 устанавливать?
Зачем ? SQLDMO это просто ещё один OLEServer который можно и просто отдельно зарегистрить на машине.
>А какая разница, посредством какого инструмента передавать запросы и
>получать результирующие наборы данных, если обработка запроса все равно
>на сервере?
Я тоже так думал, есть у меня внешняя компонента которая через ODBC запросы в тупую пихала на SQL, так вот когда я начал работать через ADODB то просто стал вытеснять из конфигурации компоненту. Так и выяснил, что в неокторых случаях авсолютно один и тот же запрос, например простейший :
select a.id from sc33 a where a.sp1917 like '1258%'
выбрать список товаров по части кода.
работает через ADODB в несколько раз медленнее ... :0(((
Стал выяснять в чём дело. Запустил трайсер перехватил запрос и челюсть у меня просто упала. Запрос через ADODB идет в тупую, as is. А через ODBC превращается в последовательность оптимизированных команд. Сначала сздаётся хранимая процедура, куда кроме текста запроса передаётся ещё какие-то параметры, а потом ещё идёт несколько вызовов процедур работы с курсором самого SQL. То есть ОПТИМИЗАЦИЯ по полной программе. Вот так.
   Alex
8 - 23.08.00 - 10:23
Полное несоответствие теории. Но в жизни встречал еще большие чудеса.
Надо будет поковырятся в описании ADO на досуге.
Кстати, не пробовал вызывать хранимые процеуры из под 1С? А также наворачивать триггера на таблицы? А то руки не доходят, а интересно.
   Winter
9 - 23.08.00 - 14:13
Можно не только вызывать хранимые процедуры, но и делать более сложные вещи. Почитай просто help, там можно почти всё, SQLDMO на много более мощьная вещь по возможностям, было бы время разобраться ...
   Alex
10 - 23.08.00 - 14:29
Спасибо, поюзаю.
 
  Рекламное место пустует
   bird
11 - 28.08.00 - 00:09
Привет!
Winter says(2):
================
Последжние пару дней тоже активно работал с ADODB, пришел к выводу что это тормоз ... По индексированным полям работает ещё ничего, а вот более сложные запросы эта штука оптимизировать не умеет.
----------------
1. ADO не тормоз. 2.По индексам любой дурак (машиша БД) "ничего" работать будет :о). Индексы для того и создаются. 3. ADO может и "доопимизировать" - например создавать _свои внутренние_ индексы, и работать много эффективнее тогда, в некоторых случаях (например на больших неиндексированных наборах - хотя не проверялось).
================
Перешел на SQLMDO, эта вещь дествительно хорошая
----------------
SQL Distributed Management Objects (SQL-DMO) is a collection of objects encapsulating Microsoft® SQL Server™ database and replication management. Как Вы видите, данная вешь призвана служить несколько другим целям...
================
Один и тот же запрос SQLMDO выполняет раз в шесть семь быстрее чем ADODB
----------------
Не бывает такого при "нормальном" использовании - а ежели наблюдается, значит есть явные ошибки использования ADO.
Alex says(4):
================
в конечном итоге все равно работа через OLEDB, только надстройки разные.
----------------
Нет, не всегда. ADO например может работать и через ODBC. Для этого в строке подключения используется синтаксис: "Driver={SQL Server};Server=MyServer;Database=MyDB;UID=...". А ежели
так: "Provider=MSDataShape.1;Persist Security Info=False;Data Source=MyServer;..." то OLEDB, и провайдеры могут быть разные.
Winter says again(7):
================
простейший : select a.id from sc33 a where a.sp1917 like '1258%'
----------------
Это он на вид только кажется простейшим, точнее он для Вас простейший - для сервера совсем нет. Тут дело может дойти и до сканирования таблицы (причем даже если и индекс определен для поля sp1917).
================
Запрос через ADODB идет в тупую, as is. А через ODBC превращается в последовательность оптимизированных команд. Сначала сздаётся хранимая процедура, куда кроме текста запроса передаётся ещё какие-то параметры, а потом ещё идёт несколько вызовов процедур работы с курсором самого SQL. То есть ОПТИМИЗАЦИЯ по полной программе
----------------
Вы малость заблуждаетесь в этой самой оптимизации. Это так называемый prepared statement. Много работы проводиться по его подготовке? - Много. СтОит ли эта работа что-нибудь? - Да, стОит, и стоит не мало. А когда это помогает (раз уж есть - то значит появилось неспроста?) - тогда, когда надо выполнить много однотипных запросов - один раз создается параметризированный ADODB.Command, его свойство Prepared ставиться в True, и много раз выполняется. Тогда можно что-то поиметь. Одноразовое выполнение prepared-запроса как правило приводит к _снижению_ общей производительности. Хранимая процедура _создается_ в TempDB, оптимизатор просчитывает оптимальный план выполнения ее, затем она компилируется, и затем только выполняется. Это совсем не дешево обходиться. ОПТИМИЗАЦИЯ начинается с текста запроса - ADO или что-угодно - только потом может сыграть роль.
================
SQLDMO на много более мощьная вещь по возможностям
----------------
Повторюсь, но это было создано для других целей, и с ним не проводилось такой оптимизации и тонкой настройки, как с ADO например - она физически не может работать быстрее - там этого просто не нужно.
================
Сергей.
   Winter
12 - 28.08.00 - 00:07
bird спасибо за хорошую лекцию.
Может быть Вы и правы что надо было просто поставить свойство ADODB.Command Prepared в True и оно бы тоже отработало так же быстро.
Но SQL-DMO это же внутренняя вещь SQL и вряд ли с ним может что-нибудь сравниться по скорости и возможностям работы с SQL.
Кстати, как мне сказали MicroSoft вроде бы прекращает продвижение и поддержку ADODB ... А в данной ситуации мне больше всего был нужен быстрый результат ! Может по этому я просто не стал глубоко рыть, а сделал то что сработало быстрее ... Век живи, век учись - дураком помрёшь.
   bird
13 - 28.08.00 - 11:28
SQL-DMO не внутренняя вещь - это всего лишь еще одна библиотека, но для работы с объектами самого SQL Server'а и для управления репликацией. Это только menegement и все. И поэтому я бы сказал, что сравнивить скорости работы несколько неккоректно. ADO имеет кучу "фишек", и они здорово облегчают жизнь - в SQL-DMO этого просто нет и не нужно.
Не знаю что сказать по прекращению поддержки ADO - _существующее_ еще до конца не отработано, и вот что-бы прекратить? А где же replacement? DAO и то поддерживается до сих пор, в нем исправно исправляют ошибки и так далее. Пишите хоть с RDO - все это будет работать гарантированно.
Успехов...
   Green
14 - 28.08.00 - 13:51
Ребята хочу сказать свое "ЗА" в пользу ADO
через это дело я на очень тормознутой тачке
довольно сносно работал с базой MS SQL (по сетке 10 М/б)
   Winter
15 - 28.08.00 - 13:59
Green ты говоришь своё за не в пользу ADO, а в пользу прямой работы c SQL Server'ом, а ADODB или SQL-DMO или ещё что это уже средства. По-моему флем этот уже затянулся, понятно уже что ADODB хорошая вещь, только надо её уметь использовать, хотя я и обошёлся средствами SQL-DMO.
   Alex
16 - 28.08.00 - 14:05
Особая благодарность bird за подтверждение правильности моих теоретических знаний по ADO.
   Sergo
17 - 28.08.00 - 14:19
А где по боле почитать об этом ADO?
   MishGan
18 - 28.08.00 - 15:58
Bird, а ты не пробовал вставлять триггеры в 1С-ную базу? Помнится ты хотел вроде бы. У меня не получилось - 1С вываливается с какой-то ошибкой. Хотя если юзать базу извне, любым другим приложением - триггер тормально функционирует.
   Alex
19 - 28.08.00 - 16:09
Читать можно на M$ или MSDN дисках. Правда на аглицком.
А триггеры у меня тоже валят базу.
   bird
20 - 28.08.00 - 16:22
Привет MishGan!
Тебе только что отмылил, повторюсь, посмотри в тексте триггера такой stmnt:
SET NOCOUNT ON
если нет, добавь и рез-т pls сообщи.
Сам не доберусь никак, работы - сплошной цейтнот, да и не горит прямо сейчас. Вообще работать должно. Проблемы могут быть с ошибками (точнее их генерацией) - но и то, можно кой-что придумать, просто проверять надо.



Список тем форума

Форум Территория 1С

Рекламное место пустует   Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Ветка сдана в архив. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует