Саныч , а как можно вставить Dlookup в таблицу? Впрочем, вопрос у меня не об этом, это так, вырвалось :)

Вопрос вот какой: идея организовать доступ к данным на основе Login'a посещает, похоже, каждого, кто работает с многопользовательской mdb. У меня это находится на стадии идеи, соответственно, прежде чем огород городить, хотелось бы выяснить все более подробно.

У меня: вход по логину, есть таблица (или таблицы) с полем ID, этот ID однозначно связан с данными о сотруднике. ID в таблицах служит индикатором доступа к данным, т.е. человек с другим ID эти данные не прочитает.

Нужно: занести Login в глобальную переменную (или куда там оно может влезть) и в запросах/формах/отчетах брать этот Login (это то же самое, что и ID) для своих целей.

Я так понимаю, что сначала нужно создать функцию, забирающую Login. Не подскажете ли как? (прошу прощения, если повторяюсь) И из нее, как глобальную переменную брать ID (тоже с примерчиком на пару строк, если возможно, например, для запроса). Правильно?

Очень сильно подозреваю, что в случае с mdb, сделать так как говорит Alexus12 было бы очень логично. Пожалуй, стоит над этим подумать поподробнее.

Например, как сделать так, чтобы разрешать или запрещать открытие формы, можно было универсальным модулем (не для каждой же формы писать код, тогда вся идея становится уж больно идейной).

Итак, таблица с пользователями уже есть (твои Users), делаем таблицу прав доступа (точнее, это ведь не права доступа, потому что эти права вполне нормально назначаются стандартными средствами, это таблица прав доступа к конкретным данным, во как). В этой таблице для пользователя с ID = '00001' ставим разные правила, например, ЗаказчикID = '00002', КлиентID = '00013' и т.д., т.е. те данные, которые ему разрешаем брать из таблицы.

В эту же таблицу с юзерами можно добавить и группы (чтобы сэкономить на таблице :), но лучше, конечно, сделать для групп отдельную таблицу). Тогда в итоге будем иметь стандартные разрешения на открытие форм (если не все из них можно открывать) и наши разрешения из таблицы Users на определенные данные. Имхо, этого достаточно, т.к. пользователь 'Vasya' не откроет форму, если ему это не разрешено, а если разрешено, то получит только свои данные. Получается, что даже код не нужен. Но недостаток в том, чтобы придумать универсальное поле для запросов, выводящее только нужные записи (опять же, слишком много разных конструкций для каждого запроса делать бессмысленно, имхо).

Как быть со сложными разрешениями типа ?
neal
А потом появиться начальник над (2) и (4) юзером и захочет видит только их записи
Может быть, сделать связь Users с таблицей доступа многие ко многим и просто для юзера Boss вставить всех клиентов? Слишком много вставлять, кроме того, при появлении новых клиентов, придется добавлять и доступ. Тут еще думать и думать, чтобы не напутать...

P.S. У меня в Access 2k3 в поле формы с параметром по умолчанию как CurrentUser(), все совершенно нормально и корректно выводится (т.е. без кода).

That's all folks...

Сорри, забыл один вопрос к маяк .

Метод не сложный и хороший. Есть вопрос: как все же реализовать доступ только к определенным данным, если, скажем, права на этот доступ будут не только у того юзера, который эти данные ввел?

Пример: менеджер "Vasya" вбивает заказ и суммы. Посмотреть их хочет ген. директор, его зам, его зам зама и т.д.

EDUDK01 , в том-то вся проблема этого метода. Поясню, в чем у нас трабла:

Есть 3 менеджера, занимающиеся клиентами "А", "Б", "В" соответственно (т.е. каждый только с одним). Этим менеджерам записи друг друга видеть нельзя (ну, там, конкуренция и все такое). Но. Есть еще бухгалтер, зам. генерального, сам генеральный. Эти привилегированные пользователи могут видеть разное. Т.е. бухгалтер (условно) записи менеджеров 1 и 2, но не 3 (типа третий работает с откатами напрямую с замом :).

Думаю, все уже поняли, что за проблема. Очевидно, что в случае нежелания делить таблицы с данными для применения встроенной защиты Access по менеджерам (у меня), приходится делать защиту самостоятельно. Эта наша защита, суть тот же механизм с двумя колесами, только медленный и корявый. Ведь делать нужно обычные группы пользователей (как отдельную таблицу) и самих пользователей (тоже таблица). Их взаимоотношения прописывать ручками, а разграничивать запросами. Но, ладно бы эти ограничения можно представить по нисходящей в плане доступа, так ведь нужно еще ограничить параллельно (1 видит 2, 2 видит 3, 3 видит 1 и т.д.). Жуть.

P.S. Если же свою защиту, как предлагает маяк , понимать как "защиту", то лучше сразу считать всех пользователей "белыми и пушистыми", тогда проблем не будет (т.е. вообще не делать никакой защиты, кроме "пароля" базы). Однако, собственная защита может быть куда как эффективней, если вспомнить что такое mdw перед AOXPPR.

That's all folks...