| |
|
|
| | Создал базу для учета и приема заказлов (такси). В ней есть Таблица Заказы. База пока не разделена на части и присутствует вся в файле *.mdb Работают с ней обычно одновременно 2 диспетчера с разных компов. При этот примерно раз в полмесяца или иногда раз в неделю возникает ситуация, что в базе в Таблице Заказы появляется запись (как правило последняя или предпоследняя), в которой все поля #Ошибка. Дальше работать с базой становится невозможно, поскольку в процессе работы эта Таблица используется, а понять эту запись она не может.
Подскажите, как исключить подобное событие. Как оно происходит я не могу отследить. | |
| |
| |
| |
|
|
| | происходит видимо когда оба оператора одновременно что-то правят.
Делите базу, и на той что будет с таблицами в параметрах ставите запрет на изменение редактируемой записи и всё такое чтобы оператры друг другу не мешали... | |
| |
| |
| |
|
|
| | Да, так вроде и выходило, что при попытке редактирования одной и той же записи двумя операторами с разных компов сбои начинались.
Базу действительно надо разделять, а то на скорости доступа по сети уже сказывается. Вот только ткните плиз пальцем, где ставится запрет на изменение редактируемой записи. Я чего-то сходу не нашел. | |
| |
| |
| |
|
|
| | Сервис ===параметры====другие====блокировка по умолчанию=======изменяемой записи. | |
| |
| |
| |
|
|
| | Вопрос заодно по этой теме. А эта блокировка изменяемой записи будет осуществляться есть база не разделена, ну то есть 2 или более человек работает с одним *.mdb файлом? Вроде как должно блокироваться | |
| |
| |
| |
|
|
| | ТАм где таблицы -=- там и делаем настройку.
Можно во всех базах такую настройку - тода одёновременно одну и ту жа запись двое пользователей править не смогут
Но есть нюанс :
некоторые лоботрясы начинают редактировать, и на полпути идут пить чай, в туалет , или покурить и в этот момент другой пользователь испытывает трудности.... | |
| |
| |
| |
|
|
| | ну это уже их проблемы будут. При попытке доступа к заблокированной записи наверняка сообщение выскакивать будет, вот пусть и смотрят из-за кого блокировка. Пока что рабочие места рядом находятся, так что в этом проблем не вижу | |
| |
| |
|
|
| |
|
|
| | Блокировка на уровне записи в MDB работать не будет, точнее без ухищрений не будет
вот это почитайте
http://sql.ru/forum/actualthread.aspx?bid=4&tid=140535&pg=-1
там же есть ссылка на описание блокировок
Если без ухищрений, то блокировка осуществялется страницами. т.е. блокируется столько записей столько влезает на страницу (под страницей понимается не кол-во строк влезающих на экран, а страницы внутренней структуры БД)
В общих чертах с блокировками так (под "блокируемой записью" далее понимается страница в которую входит редактируемая запись):
"Отсутствует" - запись к не блокируется пока пользователь осуществляет редактирование. При попытке сохранить, происходит блокировка записи и проверка не была ли изменена запись с момента начала редактирования. Если запись изменялась, пользователь получает сообщение об ошибке.
"Изменяемой записи" - Запись (страница) блокируется при начале редактирования, другие пользователи могут только просматривать. ПОсле сохранения блокировка снимается
Если записи в таблице короткие, то один пользователь может заблокировать довольно много записей этой таблицы, иногда всю.
"Всех записей" - ну тут все понятно, блокируется вся таблица. | |
| |
| |
| |
|
|
| | ссылку предложенную изучу поподробнее. там много написано. спасибо за подсказки.
А пока что разделил все-таки базу. То есть часть с таблицами, и части с формами и запросами для диспетчеров. Ну и в настройках Access на всех компах выставил блокировку редактируемой записи. Посмотрю будет ли глюк повторяться. Пока что (после внесенных изменений) сбойную ситуацию не пробовал повторить. После узучения ссылки от osmor может еще какие изменения в базу внесу. Но пока у меня все файлы в виде *.mdb | |
| |
| |
| |
|
|
| | Вот похоже из-за Блокировки изменяемой записи какая-то фигня творится. У операторов стали стираться в заказах поля откуда клиента забирать. Или еще из-за чего-то. Толи из-за разделения базы. Пока не разобрался из-за чего. В общем сейчас файлы:
Такси_be.mdb - с таблицами - на первом компе
Такси.mdb - с формами
Security.mdw - с паролями
Такси.LNK - ярлык для открытия - на первом компе
Такси.mdb - с формами
Security.mdw - с паролями
Такси.LNK - ярлык для открытия - на втором компе.
Ну по идее такие же файлы должны быть на третьем и далее компах. Не знаю правильно или нет, но файл с паролями скопировал на все компы и в ярлыке прописал путь к каждому отдельно. Хотя может нужен один файл Security.mdw и разные пути к нему с разных компов.
Пишу это все потому как не пойму откуда глюк пошел. Еще разные изменения вносил в обработки, но сейчас просматриваю и не представляю, чтобы это могло влиять.
Получается такая станная вещь. Диспетчера принимают заказ, текущие заказы висят в табличной форме, в которой данные можно изменять и у них стали пропадать из форм адреса откуда заказ. Сам не видел. Все со слов. Работают именно сейчас одновременно с двух компов. | |
| |
| |
| |
|
|
| | Блин, ну бабы толком объяснить ничего не могут. Сейчас вроде по телефону разобрался. Для них же ввел изменение, чтобы вначале при приеме заказа вбивали номер телефона и по базе будет пробиваться, не забит ли по этой базе ну типа постоянного адреса. Если забит, то поля откуда забирать заполняются сами. Предусмотрел, чтобы номер телефона первым забивался, а остальные поля обновлялись после апдейта в этом поле. А они гады номер телефона последним били, и соответственно все их поля заменялись на данные из базы телефонных номеров, ну а там почти по всем номерам пустота по адресу пока что.
Я уже и блокировки им сказал как по телефону снять. Сейчас выжду время и наверно снова надо будет ставить блокировку изменяемой записи. | |
| |
| |
| |
|
|
| | Osmor: прочитал предложенную ссылку. Много там чего написано. Часть понятно, часть не совсем. Но главное написано: действительно при разделении базы на табличную и интерфейсную(с линкованными таблицами) и при доступе к БД из разных экземпляров интерфейсной части, блокировка на уровне записи работает!
Я как раз свою базу только сегодня ночью разделил на табличную и интерфейсные. Сейчас как непонятки были пока в настройках Access сняли Блокировку изменяемой записи. То есть Открытие без блокировки идет.
Главный вопрос такой. Возможно ли возникновение глюков с появлением записи типа Ошибка, которая вызовет невозможность работы с базой, при одновременном редактировании одной записи двумя пользователями или все-таки нужно Блокировку вводить? Если вводить блокировку, то где - в свойствах Формы или в свойствах Access? Есть еще смутная надежда, что после разделения базы глюк появляться не будет, тогда фиг с ним, пусть хоть в десять рук одновременно одну запись редактируют. | |
| |
| |
| |
|
|
| | блокировка выставляется на уровне сохраненных запросов или форм.
как будет реагировать база на редактирование одной записи двумя пользователями - зависит от выбранной блокировки, см мой ответ выше.
Тип блокировки во многом зависит от условий и интенсивности работы. Если таблица активно изменяется несколькими пользователями, то я обычно ставлю "не блокировать", пользователям объясняю что делать в случае есть появится сообщение что запись изменена другим пользователем. | |
| |
| |
| |
|
|
| | Опять глюк вылез. уж не видел, чего они там редактировали, но после внесения изменений в существующую запись в Заказы, появилась запись Ошибка и распространилась на все поля этой записи. А далее база виснет. В табличной форме с активными заказами появляется при открытии сообщение Указан недопустимый объект или объект более не задан. и все - конец. Дальше работать невозможно. Дальше только ручками сжатие и восстановление базы, стирание ошибочной записи, восстановление разорванных связей и только после этого работать можно.
Подскажите как избавиться от этого. Что сделать, чтобы предотвратить. | |
| |
| |
| |
|
|
| | похоже что сетка не очень. Сейчас какая блокировка стоит? | |
| |
| |
| |
|
|
| | Сейчас блокировка не стоит. База разделена на Таблицы и Формы | |
| |
| |
| |
|
|
| | а если включить блокировку на уровне записи? Сообщения часто вылезают? | |
| |
| |
| |
|
|
| | Еще не включал. Сейчас вечером поеду, заеду включу. | |
| |
| |
| |
|
|
| | А куда конкретно ставить блокировку в разделенной базе, в табличной или в интерфейсной?
Программно это возможно как-то (в ORACLE можно :))? | |
| |
| |
| |
|
|
| | поправить базу можно так :
Делаем резервную копию (на всяк случай - всегда (правило такое есть))
сервис служебные сжать и восстановить таблицы нада, а затем отсортировать от а до я и первой окажется битая строка её удалить (строку). | |
| |
| |
| |
|
|
| | в общем при устранении битой записи так и делал. Только ключевое поле в Таблице Заказы почему-то делалось не ключевым после сжатия и восстановления и иногда разрывалась пара связей с другой таблицей.
Сейчас пока что все-таки не стал блокировку делать, а разрешил редактирование уже введенных заказов только на одном (главном) компе. А остальным разрешил только просмотр. Тем более по смыслу работы диспетчера сидят принимают заказы, а главный (старший) диспетчер один их распределяет. Правда уже вякать началь что хорошо бы изменение всем разрешить, типа того что ошибки делают и приходится старшей исправлять. Но пока не сдаюсь. Мне пока что проще запретить, чем с их глюками разбираться. (просто нет времени сидеть там и отслеживать сетевые глюки). Надо внимательно заказ принимать.
Ну и заодно купил им бесперебойник для свича. Компы-то с бесперебойниками, а свич - был без. А то возможно что глюки могли возникать при мигании электричества, когда сеть на долю секнды делается нерабочей. | |
| |
| |
| |
|
|
| | Вашу программу без данных.
Таблицы отдельно и интерфейс отдельно - можно посмотреть? | |
| |
| |
| |
|
|
| | Зачищу от данных, упакую - черкану какой объем получается | |
| |
| |
| |
|
|
| | Посмотрел получилось где-то на 1Mb после сжатия и очистки, так что высылаю по электронке | |
| |
| |
|
|
