Такая вот проблема:

В программе используется связка ADO через Provider = OraOLEDB.Oracle.1
Коннект проходит нормально.
Далее открывается MyADOQuery :TADOQuery (Select * from MyView).
Периодически, на строке
 MyADOQuery.Open;
вылетает исключение
 Access violation at address 7C910A19 in module 'ntdll.dll'. Read of address 0000000D
и все встает колом.

Систематичности никакой не наблюдается.
На моем компьютере AV где-то 30% от всех запусков программы (WinXP).
У другого клиента - всегда (100%) Win7.
У третьего - никогда (0%)Win7
ADO косячное или OraOLEDB.Oracle.1 или Я?

Может кто сталкивался?

> ADO косячное или OraOLEDB.Oracle.1 или Я?

а если зайти отладчиком в MyADOQuery.Open?

Прям сейчас нет такой возможности.
Помню, где-то глубже все это происходит. Ругань была на msado15.dll и msdart.dll

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

To Сергей М. ©   (23.11.11 11:16) [3]

Не очень понял. И что делать?

> И что делать?
либо избавляться от потоков, либо приводить их "в порядок".

Извините, опять не понял. Я  потоков не использую.

значит "следы" ведут куда то в другую сторону.

> У другого клиента - всегда (100%) Win7.
> У третьего - никогда (0%)Win7
> ADO косячное или OraOLEDB.Oracle.1

А у них одинаковые версии ADO и OraOLEDB.Oracle.1?

попробовать MSDAORA.1 (мелкософтский "переходник" к драйверам... без них работать не будет)

To clickmaker ©   (23.11.11 15:23) [8]


> А у них одинаковые версии ADO и OraOLEDB.Oracle.1?


Да, надо бы проверить.

Но вот почему у меня это 30%?
Еще интересно: если до этого запроса зайти в любой справочник или обратиться к другому режиму программы где используется dbawarecontrol, то AV не возникает???

To sniknik ©   (23.11.11 15:32) [9]

> ... без них работать не будет


Почему?

> Почему?
патамучто!

sniknik ©   (23.11.11 16:00) [12]

>
> > Почему?
> патамучто!


???

- без зимней резины машина скользит, использую фирмы хххх, что делать?
- попробуйте фирмы уууу, только без машины не получится.
- почему?

> Может кто сталкивался?

Сталкивался, сталкивался. Как же не сталкиваться. Все в своё время школотой были.

AV в неожиданных местах говорит о серьёзной порче памяти. При этом место и время возникновения AV может очень далеко отстоять от места и времени действительного бага. Это печально, но такова правда жизни, такие баги очень трудно обнаружить, часто для этого требуется внимательная ревизия чуть более, чем всего имеющегося кода. Не видя же кода сказать невозвожно практически ничего.

Типичные ошибки, приводящие к таким чудесам:

- Вызов конструктора у ссылки, вместо типа. Т.е:
MyObject.Create() вместо MyObject := TMyObject.Create()

- Обращение к удалённому объекту

- Обращение к объекту по неинициализированной ссылке

- Передача указателя на буфер вместо буфера в var-параметр

- Доступ за пределы буфера

И ещё целая куча подобных тупых ошибок, большинство которых являются банальными описками, а потому очень сложно отыскиваются "замыленным" взглядом.
Очень сильно мешает делу так же соблазн обвинить во всём "мультипоточные коллизии", "кривые драйвера", "тупую винду", Била Гейтса, жидомассонов и погоду на Марсе.

Настраивайтесь на максимально самокритичный лад, выспитесь, сядьте в удобное кресло и -- вперёд за ревизию кода начиная с 17-й строки.

To DiamondShark ©   (26.11.11 15:05) [15]


> И ещё целая куча подобных тупых ошибок, большинство которых
> являются банальными описками, а потому очень сложно отыскиваются
> "замыленным" взглядом.
> Очень сильно мешает делу так же соблазн обвинить во всём
> "мультипоточные коллизии", "кривые драйвера", "тупую винду",
>  Била Гейтса, жидомассонов и погоду на Марсе.
>
> Настраивайтесь на максимально самокритичный лад, выспитесь,
>  сядьте в удобное кресло и -- вперёд за ревизию кода начиная
> с 17-й строки.
>
>


Абсолютно согласен: никогда не позволяю себе такого.
Если разберусь, расскажу.