В конторе, где имею честь работать,
десятки пользователей, хренова туча задач
обмена Фокс-Оракл -Фокс, многие из
них, за исключением единиц, я сам и написал.
И работают они каждый божий день как часы год за годом
и глючат кране редко.
Но еще Станислав Лем писал, 100 раз человек есть картофель,
но один раз, картофель ест человека или что-то в этом роде.
Есть одна бухша, у которой время от времени при связи с Оракл через ОДБС
10 тонкий клиент идет ошибка -системная ошибка 132 sqora32.dll не может быть
из-за этой ошибки загружен. Аналогичная задача на других компах
никогда не глючит. И у тетки ошибка появляется не каждый день, а вне всякой системы.
Иногда просто не дает работать.
Причем попытка использовать 11 тонкий клиент дает ту же самую проблему.
Поскольку dll с аналогичным именем,
но другая по размеру и сути бывает и на других клиентах,
то теоретически может быть ситуация, что эта библиотека как-то застряла в памяти,
и когда пишем sqlstringconnect даже указывая конкретный клиент, система решает,
что он уже есть, пытается его задействовать, а он чужой.
Это только рабочее предположение.
clear dll.
=sys(1104)
sqldisconnect(0)
Перед новой коннекцией не помогли устранить ошибку.
Я решил поумничать, нашел в win32 две функции
Declare Integer GetModuleHandle In kernel32 String @lptstr
Declare Integer freelibrary In kernel32 String @lptstr
Вызываю до коннекции
hd= GetModuleHandle('sqora32.dll')
if hd >0
=freelibrary(hd)
endif
lcconstring = 'Driver={Oracle in instantclient10_2};UID=....blablabla'
hconn = SQLSTRINGCONNECT(lcconstring)
Этим я надеялся избавиться от попавшего в память чужого клиента
При первом запуске все ок
А при втором вылет в системную ошибку -с00005
То есть идея была тухлой в самом начале
Первый SQLSTRINGCONNECT(lcconstring)
dll в память загрузил
Хотя потом sqldisconnect(0)
clear dlls
Он все равно остался как-то в памяти, и следующий
SQLSTRINGCONNECT(lcconstring)
его туда больше не загрузил
Это я описываю ситуация у себя на компьютере до отладки,
а у меня ошибки , что была у бухши, и не было.
То есть у нее бы код тоже скорее всего тоже бы упал
Вот и думаю, а в какой же момент все-таки Фокс
грузит dll Оракл клиента , если не при коннекции.

Вполне возможно что конфликтует третий софт - антивирус, прокси-клиент, даже внешне безобидные програмки могут загружать свои dll в другие процессы, либо же перехватывать системные вызовы и тем самым "ломать" и оракл-клиент и другой софт.
Я бы начал с изучения того что подгруженно в память процесса на этой машине и сравнения с другими, где всё работает нормально.

Фокс сам, естественно, не грузит dll odbc драйверов - это делает odbc менеджер - виндовая компонента. И делает это в момент начала использования этого драйвера. Насколько я помню, после использования эти dll не выгружаются (да и не нужно их выгружать).

> Аналогичная задача на других компах никогда не глючит

() сменить кабель сетевой, сетевую розетку..., комп (зачистить, сменить) - так дешевле бывает, по затратам усилий...

()() Есть у нас одна дженщина, что-то непонятно спонтанно, редко глючило (то "запись заблокирована", то еще что-то), две сетевые (изернет) розетки рядом. Меняли розетки - ошибка осталась. Сменили комп (ну, тут уж казалось бы!) - осталась... Осталось завести ей нового юзера в сети что-ли (может под ее СИД что-то)...

()^3 Фокс иногда не справляется с ОС-ями современными (или они с ним). Недавно, простая процедура - есть 4 файла ОДИНАКОВОЙ структуры, сделаны COPY TO из одной проги. Делаю 3 раза APPEND FROM (имя) чтобы сделать из них один "большой" общий файл (<200М), никаких фильтров, никаких ничего, просто USE - APPEND - APPEND - APPEND. На локальной машине делается за 10 сек, на удаленном сервере (он близко) - 30 мин! Смотрел всякими диспетчерами задач - проц (одно ядро, конечно) 30 мин загружен на 100%, идет скоростной (?) байтоообмен процесса фокса с очередным добавляемым файлом, что делает фокс 10 мин/файл - хз...

Как ИК и накаркал - фокс перестанет работать в виндах рано или поздно... А жаль (



Исправлено 2 раз(а). Последнее : of63, 16.01.22 18:03