В программе используется объект TAdoConnection  для работы с бд скл сервера. Иногда после долго работы (многочисленных вызовов хранимок бд, шатдаунов скля (когда идут бекапы)) объект TAdoConnection выдает access violation при обращении к нему (попытка вызова Close), хотя  я его освобождаю только в destroy приложения (верне сервиса). Close могу юзать часто, при различных возможных ошибках соединения (например недоступность скля), чтобы инициировать реконнект..

вопросы:
- правильно ли так использовать TAdoConnection?
-почему может падать объект?
-что делать чтобы этого не было (или такое бывает и он корректно освобождается и нужно лишь пересоздать его..) ?

> -почему может падать объект?


Если именно AV и именно при обращении к TADOConnection, то стопудово объект уже уничтожен.
Смотри, где идут вызовы деструктора. Сам явным образом убиваешь, убиваешь владельца (Owner) и т.д.

> Сам явным образом убиваешь, убиваешь владельца (Owner) и
> т.д.


ох непросто это... этот сервис 7 дней проработал до этой ошибки делая всевозможные манипуляции с данными... но никогда явно не освобождая конекшн.

конекшн часто используется в для вызова хранимок и передается в соответствующее свойство, т.е. код вида:




но ведь  storedProc.Free; не вызовет освобождения моего объекта конекшена? это было бы слишком заметно)

и как может смениться owner при  FConnection := TADOConnection.Create(nil);  ??

я конечно поставлю заплатку и на случай убитого adoconnection, пересоздам его (предварительно пытаясь сделать freeandnil в try..except). но не породит ли это утечку ?

> ох непросто это... этот сервис 7 дней проработал до этой
> ошибки делая всевозможные манипуляции с данными... но никогда
> явно не освобождая конекшн.
>

Никогда не говори никогда.

> только в destroy приложения (верне сервиса).
сервис это поток... создание/уничтожение делается в основном потоке, работа (execute) же в нем самом.
для роботы ADO нужно инициализировать com модель для каждого потока, или в каком то модуле само, для основного.
что произойдет если инициализация/закрытие модели (основы) происходит в дополнительном, а надстройки в основном после закрытия основы? AV точно может. а редко потому что память занимаемая объектами не моментально затирается, а может висеть еще какое то время. типа объект призрак.

в общем не вали на ADO, а проверь тщательнее свой код.

и еще
> TADOStoredProc
... ... .... слов уже нет.

переписать все на property Connection:TADOCONNECTION read FConnection
сам FConnection скрыть, что ни одна собака без property не достучалась

, на set этого проперти поставить проверку на валидности / логатор / соли по вкусу

AV ©   (01.03.12 10:06) [6]
это называется "замазать глюк", вместо разбора/искоренения причин.
и к тому же не поможет если проблема не в отсутствии/уничтоженности объекта (к стати если без обnilения, тоже), а в чем-то связанном типа [5] первый абзац.

> и еще
> > TADOStoredProc
> ... ... .... слов уже нет.


можете пояснить плиз?

как? без слов то...
ну, если коротенько... это атавизм сделанный для привыкших к BDE для быстрого перевода. в "чистом" ADO такого понятия нет. процедуры есть, а вот StoredProc нет.
в общем, это признак ламеризма для тех кто понимает.

> sniknik ©   (01.03.12 08:03) [5]

в основном потоке сервиса при старте делается
CoInitializeEx(nil, COINIT_MULTITHREADED);

другие потоки юзят свои конекшены (с предварительным вызовом CoInitialize(nil);), между потоками конекшены не шарятся.

> в общем, это признак ламеризма для тех кто понимает.

а как надо? покажете эталонный пример работы с хранимкой?

и является атавизм столь критичным, если получая результат хранимок я бегаю по рекордсетам, а не датасетам, избегая навигационных тормозов..?

на словах все чудно, но слова мало, что говорят... о происходящей реальности.

> а как надо? покажете эталонный пример работы с хранимкой?
нет. меня это уже давно "достало". хочешь поищи в старом. или в справке ... по ADO, это не в дельфи.

> если получая результат хранимок я бегаю по рекордсетам, а не датасетам, избегая навигационных тормозов..?
ламеризм. как есть ламеризм. в чем по твоему разница? и откуда берутся "навигационные тормоза"? не думал о том чтобы их уволить? :)

если кто-то готов проинспектировать код и найти первоисточник причины за достойную оплату, пишите: alex_for_chat@mail.ru

(организуем удаленное соединение с нашим ПК с делфей)

Обнаружил многопоточное использование TADOCONNECTION, вопрос - критич. секциями это можно разруливать или же строго по конекшену на поток делать?

> или же строго по конекшену на поток делать?
проще.

а по идее можно и вообще без критических секций и т.д... НО, придется перейти на прямое использование COM объектов ADO, без VCL-ных оберток.
в чистом виде ADO потокобезопасен... но, без этого никак, 1 коннект будет ставить запросы в очередь... если конечно не делать их асинхронными, а если сделать то потоки не нужны, но нужна очередь обработки сообщений (усложнение в потоке). такой вот парадокс.

> или же строго по конекшену на поток делать?

А это смотря что хочешь получить, с несколькими соединениями проблем обычно меньше и запросы могут выполняться паралельно, а не становиться в очередь.

С одним выше надежность