![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
зависание при запуске с расшаренного диска [D7, MSSQL]
srgsoroka © (2008-03-29 17:16:00)Доброго дня!
Приложение для записи в базу данных несложной таблицы.
Состоит из клиента, application server(Midas - apartment)
и серевер базы данных ms sql. Во время операции поста клиент вдруг зависает, причем это происходит непериодически, при интенсивной работе юзера примерно 5 - 10 раз за день.
Аппсервер не зависает, в базе блокировок не происходит. И саму запись постит. Единственное что меня смущает - это то что сам exe клиента находится на расшаренном диске. Но сеть нормальная - пробовал перегружать сеть - работает нормально. Уже неделю с этим вожусь и не могу понять причину. Если кто-то может подсказать буду благодарен. Да, в журнале клиентской машины (Windows XP) абсолютно ничего нет. Ни предупреждений, ни тем более ошибок.
srgsoroka (2008-04-03 17:35:00) [1]Вот уже 4 дня работает на терминальном сервере. Жалоб нет.
Вроде бы проблема решена, но осадок нерешенности остался.
Все таки причина зависания так и не была найдена...
ЮЮ (2008-04-01 05:31:00) [2]> Во время операции поста клиент вдруг зависает,
Почему бы не предположить, что при определенных условиях возможен и бесконечный цикл в методе "поста".
Если юзеру можно это доверить, запусти ему программу под IDE - пусть поработает до зависания, а ты - под отладчиком - после.
srgsoroka (2008-03-31 18:46:00) [3]на этом же сервере лежат также разные файлы word, excel но никаких проблем не возникало - не зависали никогда ни при открытии ни при сохранении.
srgsoroka (2008-03-31 18:42:00) [4]А может быть ограничения на число подключений? Я не знаю как там работают все эти библиотеки которые используются клиентом, но в первую очередь ведь смотрить в директории старта, поэтому возможен, наверное, вариант, когда вызов какой-нибудь процедуры с библиотеки приводит к новому сетевому подключению?
Anatoly Podgoretsky (2008-03-31 18:28:00) [5]К сетевым протоколам это отношения не имеет.
srgsoroka (2008-03-31 17:48:00) [6]Переставили сегодня юзера на терминал сервер - полдня проработал без никаких проблем. Т.е. получается что точно проблема в расшаренном диске.
Поискал в сети что-то - то сразу начинаются сетевые протоколы, много чего наворочено, короче делается не по себе. Надо, наверное, начинать разбираться в сетевых протоколах...
Anatoly Podgoretsky (2008-03-31 11:58:00) [7]> ЮЮ (31.03.2008 10:10:15) [15]
Не все, это только часть проблем - или перегрузка сети, или перегрузка сервера и его подсистем.
А есть еще более страшные вещи, такак как скажем блокировки.
ЮЮ (2008-03-31 10:10:00) [8]Сейчас тоже у заказчика столкнулcя с подобным.
Могу от себя добавить, что в случаях, когда запуск расшаренного ехе затруднитлен, в те моменты и копирование его в локальную папку выполняется недопустимо долго - от полуминуты и более.
А когда копирование идет без проблем, то и запуск расшаренного ехе-щника не вызывает затруднений.
Так что все сводится к сетевым проблемам и возможностям.
Смирнов (2008-03-31 06:45:00) [9]Была похожая проблема, файл бд (mdb) лежал на расшаренном ресурсе, разрывалось соединение с бд, потом приходилось восстанавливать базу (ошибка о неверном формате файла). Решилась проблемма заменой сетевой карты на файл-сервере. Хотя просто копирование файлов проходило без проблем.
Slym (2008-03-31 06:16:00) [10]может будет достаточно только midas.dll,rtl/vcl.bpl на клиента перенести?
srgsoroka (2008-03-30 21:52:00) [11]Спасибо. Завтра на работе этим и займусь.
Anatoly Podgoretsky (2008-03-30 13:45:00) [12]Да если есть домен, то обновление делать политиками.
Anatoly Podgoretsky (2008-03-30 13:44:00) [13]Приложение перевести на локальную машину и при старте проверять на обновление с сервера.
Проблема видимо в том, что идет борьба за ресурсы - dead lock
P.S. администратора заменить, поскольку он проедает деньги фирмы.
Германн (2008-03-30 01:17:00) [14]
> В чем конкретное применение его к данной проблеме?
>
Добавлю. Отмазки типа:
1. "тяжело обновлять программу на 40 компьютерах". А как же работают "нормальные" админы при 400 компах в сети?
2. "где то может забыть". Полное несоответствие служебному положению.
3. "где то юзера не будет". А на хрена тут нужно присутствие юзера?
ну никак не пройдут в нормальной фирме.
Johnmen (2008-03-30 00:44:00) [15]
> srgsoroka (29.03.08 23:55) [6]
> Есть такое правило - клиент всегда прав
Такое правило есть.
В чем конкретное применение его к данной проблеме?
Германн (2008-03-30 00:36:00) [16]
> Если админу тяжело, то м.б. стОит поискать другого? Более
> ответственного и менее занятого?
>
Согласен полностью. Особенно с учетом того, что не админ, скорее всего, платит деньги, а ему его фирма платит. И похоже зря платит.
srgsoroka (2008-03-29 23:55:00) [17]Есть такое правило - клиент всегда прав (т.к. платит деньги).
Но с другой стороны хотелось бы разобраться во всем этом - чтобы знать что
можно делать - что нельзя.
Johnmen (2008-03-29 23:46:00) [18]Данный путь - верная дорога к проблемам.
Если админу тяжело, то м.б. стОит поискать другого? Более ответственного и менее занятого?
srgsoroka (2008-03-29 23:44:00) [19]Дело в том, что работает примерно 40 клиентов, которые запускают эту программу с расшаренного диска. Я довольно часто, примерно раз в неделю делаю обновления. Поэтому для админа тяжело обновлять программу на 40 компьютерах - где то может забыть, где то юзера не будет и т.п. Да и время забирает много, поэтому он хочет обновлять только 1 файл (правда, там еще есть bpl, файлы отчетов и т.п.). Поэтому он и положил его на расшаренный диск - чтобы быть уверенным что все юзеры пользуются одной и той же версией.
Johnmen (2008-03-29 22:11:00) [20]Я не понимаю, зачем себе выдумывать проблемы, чтобы потом маяться с их решением?