vmag
Я тоже это имел ввиду...
- макросы не обязательны.
- можно обойтись стартовой формой (например формой ввода пароля).

Ага, спасибо, я уже поковырялся, попробовал, вроде немного разобрался

aleckoLekks, сделаю база будет закрыта полностью, щас прога тестируется, к тому времени как база будет создана думаю и тестирование закончится, тем более что прога создана в 2007-м Аксе (идея 21658915 ).
к разделению ролей это конечно отношения не имеет.

Тестовая база тута
https://yadi.sk/d/V-eVUH003ahEv6
mso 2007

Ничего не найдено, владелец удалил и т.д. (((

__MichelleОзверин,

Область переходов - это аналог окна базы данных, она приклеена слева, как dock-панели приклеиваются.

__Michelle, спасибо за доступное разъяснение, а то я что то в ступор по этому вопросу впал))) Ибо с 2007 начал)))

В общем, подытоживая:
- парольный доступ и последующее меню приложения, зависимое от роли;
- для сокрытия от пользователя области переходов и ленты (ну или окна БД) - параметры запуска БД или рантайм.
С учетом невысокой сложности БД и низкого уровня подготовки, но высокого любопытства и чрезвычайной криворукости предполагаемых пользователей склоняюсь к рантайму.

Поправьте, мастера, плиз.

P.S. alecko, интересно будет посмотреть на результат все таки. Планируется еще БД, которая будет лежать в ну очень широком доступе и бесконтрольно, поэтому желательно максимально защитить ее )))

alecko, понял, тогда по готовности базы, если не найду способов, которые меня устроят.

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

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

aleckoLekks, вот пример -открывать в доверенной зоне, вирус тотал

Ну как то так я себе это и представляю. Попробую пока реализовать подобное, но попроще, именно от дурака, имеющимися средствами.

Predeclared, вопрос не по теме топика, но к Вам ))))

PredeclaredLekksНа всякий случай схема данных...
Сомнения меня не обманули.

Блин, мне это теперь спать не дает. Самому что-то не нравится, а что - не понимаю. Надеюсь на мнение опытных разработчиков. Что не так, и что можно поменять?

Predeclared, так виднее )))
И по целостности данных, если можно, поподробнее....

Ошибку с отсутствием ключа в таблице SuspectData исправил.

По трем ключам: это меня больше всего и смущает, встречал такие связи, но весьма нечасто. Можно конечно разбить на три таблицы со связями с Accounting и Officers соответственно, но что это даст в плане целесообразности и дальнейшей обработки?

PredeclaredКасаемо схемы данных, хотелось бы определиться с терминологией:
1. Табличка OffPlace описывает места нарушений?
2. Что описывает табличка Changes?
3. Зачем вы людей в своей модели разделили по разным табличкам на нарушителей и сотрудников?

Ну и опишите нам постановку задачи, что должна описывать эта модель.

По порядку:
1. Да, места нарушений.
2. Номер смены сотрудника.
3. Нарушители и сотрудники - это две разные категории. Сотрудники выявляют нарушения со стороны иных лиц, которые, собственно и являются нарушителями.

Ну и задача - учет выявленных нарушений, при этом обязательны сведения о том кто выявил, кто зарегистрировал и кто будет обрабатывать нарушение (поэтому три поля в основной таблице). Учитывается также результат обработки нарушений (Penalty). Последующий анализ - практически по всем полям основной таблицы (количество и тип нарушений за период, нарушения выявленные отдельным сотрудником и т.п.).

В общем-то посредством "мышкотыкания" вполне себе рабочая база для минимальных целей получилась. Но хочется более серьезного, чтоб оставил и работало.