|
|
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Такая ситуация: - У каждого сотрудника в офисе есть клиентская часть(Access), а данные в виде файла data.mdb лежат на сервере.В клиентской части таблицы прилинкованы к data.mdb и соответственно работа осуществляется через сеть. Если кто также работает, или у кого есть какие мысли: - Как быстро отключить(вывести) всех пользователей от(из) data.mdb для восстановления или др., действий.Администрированием сервера занимается другой человек соответственно прав нет. Заранее всем спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2003, 15:38 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Если прав нет - или надо их взять, или пусть этот другой человек и срубает всех. После пары раз срубаний сотни юзеров админы обычно дают права :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2003, 15:44 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Встроенных средств нет. Есть только возможность запретить подключение новых пользователей, но это тебе не подходит. В твоем конретном случае наверное прийдется сделать что-то похоже на: 1. Создать таблицу с базе с данными с одним булевым полем , в котрое будешь записывать True - если надо всех выкинуть 2. На клиенте создать скрытую форму с таймером (на n-минут) По нему будет повереяться булевое поле и выводиться сособщение о том, что надо базу закрыть. Желательно, принудительно не закрывать, люди все-таки могут работать (да-да и такое бывает - сидят и работают, вместо того чтобы в ГО играть :) ). Проверка 1-го значения каждые n-минут особой загрузки на сеть не даст. З.Ы. Все это ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2003, 15:49 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
2 Сенин Виктор Иногда все-таки надо принудительно отрубать. Рухнула база - новые пользователи не подключатся, а старые продолжают работать ни о чем не подозревая. Надо рассылать сообщение и через пару минут брать палку и выгонять всех из базы. Кто не спрятался - я не виноват. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2003, 15:52 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Для > Senin Viktor Большое спасибо за совет, но это подходит когда база не рухнула.А если она упала и требуется срочное восстановление(а какой-нибудь юзер вышел покурить)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2003, 15:55 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
2Лоху, тогда я бы завел еще одно поле типа Отрубить ПринудительноЧерез5минут=True/False для этого способа админские права не нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2003, 15:57 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Еще одна идея - передавать данные об открытых формах/отчетов. Тогда будет легко принять решение об отрубании юзверя. Так же не помешало уведомление оставить о принудительном закрытии ( Net Send вроде бы) З.Ы. Во на придумывал, может и мнетакое заказчику сделать (еще не просил) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2003, 16:05 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
2 Виктор Сенин Если база рухнула - надо как можно быстрее всех срубить. А не ждать пока у клиента какая-то формочка проснется через 5 минут и начнет что-то закрывать. За 5 минут пользователь в базе с рухнувшими индексами может таких чудес натворить, что ты потом устанешь это разгребать. Кстати, из базы автоматическое закрытие самой себя может и не получиться. Это только Мюнхаузен так умел. А в жизни случаи разные бывают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2003, 16:22 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
В добавление к вышесказанному... Можно создать таблицу с полями: ProcessID - AutoNumber UserName - Text ClientDBName - Text (Это на случай если клиентских частей несколько) StartTime - Date/Time LastConfirm - Date/Time CloseTime - Date/Time и пусть скрытая форма с таймером (на n-минут) (по В. Сенину) по открытию добавляет запись, прописывая UserName, ClientDBName и StartTime, а потом каждые n-минут проставляет текущее время в LastConfirm (типа:"У меня пока всё О'Кей"), и наконец на закрытие ставит время в CloseTime. Сей журнал позволяет решать несколько задач, как то: - видеть кто работает с базой в текущий момент (и только их беспокоить на тему: "А не сходить ли вам пока покурить?") - видеть кто прекратил работу аварийно (в CloseTime будет пусто) - следить кто, как часто и как долго работает с базой - вычислять наиболее загруженое время или число наибольших одновременных подключений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 00:42 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Навскидку я бы сделал так: 1. Раз быстро, то делаем частый таймер (раз в 10-20-30 сек), обращающийся к таблице из одной записи, в которой живет одно поле да/нет (надо что-то делать или нет). 2. Если надо, то смотрим другую таблицу, где сидят комадны клиентской бд (по определению юзера код не читают, иначе с ними надо бороться)) 3. Соответственно, либо складываем в третью таблицу список названий машин/логинов/мобильных телефонов текущих пользователей или (в случае принудительного выхода, закрываем текущие формы и по желанию вешаем аксес в цикл или закрываем оный. Нда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 01:02 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
А вообще, раз уж пошла такая пьянка, как уже сказали выше, пусть они регистрируют свое появление и выход в любом случае, админу, даже если не лениво будет ежедневно смотреть в data.mdb, рано или позно надоест заниматься вредительством, что даст он-лайн информацию о подключениях. На всякий хитрый зад (как, или почти как, говорил мой ротный, на всякий хитрый зад есть перед с винтом. Он же: на перед с винтом есть зад с закоулком)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 01:15 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Ещё один вопрос: - А сколько ресурсов ест таймер.И если у юзера слабенькая машина, как это отразиться на работе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 10:22 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
если база осыпается - путь тебе к SQL серверу, не делай себе проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 12:06 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Действительно самый красивый выход - база на сиквеле (MS SQL). Таким образом решаются проблемы с отрубанием, поскольку на сиквеле такой фокус делать не придется, в процедурах можно наваять единые для всех юзеров запросы и использовать их где необходимо? да много чего вкусного моно наворотить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 12:33 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
если база осыпается - путь тебе к SQL серверу, не делай себе проблем. Дело говорят, но можно еще и файл влажок создавать на серваке! База мол осыпалась. А при открытии и нажатии на контролы или даже по времени флажок проверять! И если трындец пришел - выгонять юзвера палкой! Или вместо файла завести другую базу в которой буду жить самый минимум настроек и которая по определению осыпаться не должна из-за малого кол-ва изменений, только запросы! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 12:37 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Господа, а никто не задавал себе вопрос - если все так просто (с периодическими проверками), то почему сам аксес так не делает? Ведь есть же в базе этот самый флажок (адын байт в заголовке). Когда пользователь начинает что-то глобальное - выставляется в 1. Заканчивает что-то глобальное - сбрасывается в 0. Если отвалился не успев допеть до конца - это и есть рухнувшая база. При подсоединении к базе аксес этот байт проверяет - если не 0, то "База требует восстановления и т.п.". Кстати, когда база падает так что потом не поднимается - я этот флаг руками сбрасываю . Данные конечное кривые выходят, но все лучше чем ничего. Так вот, если все так просто как вы говорите - почему это не есть стандартное поведение аксеса? Где то должна быть засада, жопой чую но сформулировать не могу. Ведь не зря же аксес только при запуске это проверяет, и не пытается прервать работу пользователя в произвольные моменты времени. если база осыпается - путь тебе к SQL серверу, не делай себе проблем. Неправильно. Если база осыпается - то надо устранять причину, а не переводить все на SQL, Oracle и т.п. Если все хорошо - база не должна падать чаще чем раз в месяц (да и то при большой нагрузке). Без устранения причины глюков и с MS SQL могут быть траблы. Например, глючит сетевуха на серваке. Аксес просто падает, MS SQL живет, но херово, все тормозит, пользователи кричат, программеры разводят руками, заканчивается все тем что админы покупают еще гиг оперативки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 13:17 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Лоху : крайне не согласен с фразой >должна падать чаще чем раз в месяц (да и то при большой нагрузке). считаю что база не должна падать никогда. и это главный критерий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 13:28 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Я тоже так считаю. Это идеал. Но недостижимый. А вот не чаще чем раз в месяц (при 150 юзерах) - это не идеал. Но вполне достижимый. Если раз в день - то это болезнь. Ее надо лечить, причем самое главное - устранить причину болезни. Если база требует восстановления раз в месяц - это нормально. Только из за этого переходить на SQL Server не нужно. Если база падает 5 раз в час - ну значит это глобальная жопа где-то, и смена платформы просто скроет ошибки (ошибки сети например) и сделает их еще более трудноисправимыми. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 13:41 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Вдогонку. Есть много из-за чего стоит переходить на MS SQL. Большие объемы данных, много юзеров, сложная аналитика, повышенные требования к безопасности, и т.п. Все это я понять могу. Не могу понять когда люди переходят на MS SQL имея базу в 15 мегабайт, с которой работают 3 пользователя. Причем переходят потому, что не смогли в аксесе резервное копирование наладить, или не смогли глючный хаб поменять, или кто-то им сказал что в аксесе нет full outer join'а, или кто-то им сказал что MS SQL - это круто, или много чего еще. Так же не могу понять тех, кто рекомендует другим перевести все на MS SQ при тех же условиях. У аксеса своя ниша. Не надо за хлебом ездить на самосвале, за хлебом надо пешком ходить. Обратное тоже верно. Слишком часто в нашей стране на основе настольной СУБД (аксес) делают корпоративные системы. Тоже бред. Каждой задаче - свои средства ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 13:50 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Надо мне твое высказывание к себе в копилку бросить ... люблю я статистику собирать. только мне слегка сомнительно что аксессовская база бдет жить при одновременной активной работе 150 юзеров. на ввод данных могу себе представить что в один момент времени пытаются одновременно добавлять записи человек 5 ... а вот на аналитические-статистические запросы, которые тянут много данных уж больно мне сомнительно что больше двух единовременно уживутся... неужели я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 13:53 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
только мне слегка сомнительно что аксессовская база бдет жить при одновременной активной работе 150 юзеров Ну у меня же живет Не всегда 150, чаще примерно 100, опять таки большинство не загружают базу сложными запросами. Но явно больше 5 человек данные оперативно добавляют редактируют. Аналитико-статистические запросы - тут не буду возражать, выгружать их в MS SQL и крутить их там красивым олапом. Не потому что больше двух не уживутся, уживутся еще как, но слишком медленно это будет. Устанут юзера ждать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 14:09 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
>> Аксес просто падает, все тормозит, пользователи кричат, программеры разводят руками, заканчивается все тем что админы покупают еще гиг оперативки << Это я распечатаю метровыми буквами и в рамочке повешу!!! Вот только на дверь какому отделу? Потому что так оно и есть. Админ бьет себя пяткой в грудь, что сеть и все остальное работает нормально, и нет оснований ему не верить. Можно ли в этой ситуации определить откуда на самом деле ноги растут??? И еще, плз, про таймер - знает кто-нибудь, сколько он ресурсов ест? Пока эта модель кажется самой оптимальной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 14:10 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
LDBViewer.exe Он показывает кто (с какой машины) оставил базу в рухнувшем состоянии - в столбце Suspect у негодяя True. Можно через ADO (OpenSchema не помню с какими параметрами) тоже самое посмотреть. Вот эту информацию и анализируй. Если с одной машины базу роняют - выкинуть машину, если с одного сегмента - выкинуть хаб, если вообще хаотично - выкинуть сервер. З.Ы. Желательно везде поставить как можно более одинаковый софт, т.е. по возможности одну систему, с одинаковыми сервиспаками, один мсофис, тоже с одинаковыми сервиспаками. Чем более гетерогенная среда - тем более геморройная жизнь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 14:21 |
|
||
|
Поделитесь опытом
|
|||
|---|---|---|---|
|
#18+
Для Лох Позорный спасибо за советы. Если есть этот самый LDBViewer.exe кинь пожалуйста на почту kroenko@mail.ru, или ссылочку какую-нить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2003, 15:17 |
|
||
|
|

start [/forum/topic.php?fid=45&msg=32188227&tid=1680982]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 198ms |
| total: | 346ms |

| 0 / 0 |
