Если будет разная структура данных , то лучше писать разные приложения. В этом случае, объединить настолько разнотипные приложения "под одной крышей" становиться слишком сложно.

Самый простой подход к разграничению прав - это доступность/недоступность (видимость) определенных элементов интерфейса и пунктов меню. Но сам интерфейс и структура данных при этом остаются не изменными вне зависимости от прав доступа.

Да, можно сделать разные отчеты. Один доступен одному пользователю, другой - другому. Разграничение по доступности соответствующих пунктов меню или кнопок, вызывающих эти отчеты.

============
Идеология файл-серверного программирования (хранилище данных в таблицах DBF) и клиент-серверного программирования (хранилище данных MS SQL, Oracle, MySQL и т.п.) достаточно сильно отличаются.

Это значит, что не получится написать приложение для DBF-таблиц, а потом "по быстрому" перевести его, например, на MS SQL. Придется не просто "переводить", а, по сути, писать заново. Новое приложение.

Основные критерии выбора между файл-сервером и клиент-сервером примерно такие:

-) Согласен ли клиент платит достаточно большие деньги на покупку серверной базы данных (MS SQL, Oracle и т.п.). Речь идет о тысячах долларов.

-) Каков предполагаемый объем базы данных. Для таблиц DBF существует ограничение на размер файла в 2 ГБ (не всей базы данных, а именно одного файла). Ну, обычно это где-то порядка нескольких десятков миллионов записей в одной таблице.

-) Предполагается ли работа через сторонние приложения напрямую с базой данных минуя написанное приложение.


============
Какой способ хранения данных будешь использовать, принципиального значения не имеет. Схема разграничения прав доступа будет приблизительно одинаковая:

Должна быть дополнительная служебная таблица (или набор таблиц), в которой по логину пользователя (то, что пользователь укажет при входе в программу) будет выполняться анализ какие пункты меню и объекты интерфейса данному пользователю доступны, а какие - нет.

Соответственно, это надо будет учесть при инициализации соответствующих объектов интерфейса.

Игорь, я в курсе :).

Но в данном случае я сознательно все упростил.

Да, действительно, файл-серверное приложение отличается от клиент-серверного вовсе не способом хранения данных, а тем, где физически происходит обработка этих самых данных.

Если на клиенте - это файл-серверное приложение; если на сервере - это клиент-серверное приложение; если и там, и там или еще на каком слое - это уже многоуровневое приложение.

Но все дело в том, что для того, чтобы это узнать надо "вскрыть" само приложение и посмотреть как оно там "тикает". В большинстве случаев, это не представляется возможным, поэтому ориентируются на некие "внешние" признаки. Т.е. именно на способ хранения данных. Хотя, конечно, по большому счету, это ни о чем не говорит.

Ну, и с точки зрения собственно написания приложения. Написать клиент-сервер на таблицах DBF значительно сложнее.

Хотя вот файл-серверное приложение на серверных базах данных пишут сплошь и рядом. Обычно это является следствием того, что приложение изначально было написано как файл-сервер для таблиц DBF, а потом его "по быстрому" перевели на серверную базу данных.

Krushinskaya OlgaВладимир!
А вот вы посоветовали для одних пользователей показывать какое то меню, для других скрывать.
Это что, во всех формах, отчетах, меню анализировать, кто вошел в программу, тому то и показывать?
Так это просто ужас какой то. Я запутаюсь.
Или как то по другому можно сделать?
Это все не так страшно как выглядит.

У пунктов меню есть такая опция SKIP FOR (...). Если указанное выражение принимает значение .T., то такой пункт меню становиться недоступным. Если .F., то снова активизируется.

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

Соответственно, невозможно будет вызвать формы, связанные с этими пунктами меню.

Можно объединять флаги для пунктов меню через SKIP FOR (...) OR (...) AND (...)

С кнопками и объектами на формах и ToolBar несколько сложнее. Но это решается через создание классов-родителей, как для самих форм, так и для объектов на форме. Все существующие объекты создаются как наследники этих классов-родителей.

У всех объектов создаются 2 свойства:

CheckAccess
ModeAccess

Для свойства CheckAccess создается Assign - метод.

При инициализации формы (в INIT-формы) дается команда вроде

ThisForm.SetAll("CheckAccess",.T.)

Такая команда автоматически изменяет значение свойства CheckAccess у всех объектов формы, у которых оно есть. Сам факт модификации запускает на выполнение событие CheckAccess_Assign().

В свойстве ModeAccess пишешь условие доступности данного объекта и проверяешь выполнение этого условия в CheckAccess_Assign()

Т.е. получаешь механизм автоматической настройки доступности объектов. Надо будет только изменять значение свойства ModeAccess в каждом объекте, если это необходимо.

Но это "тонкая" настройка для каждого объекта в отдельности. Обычно можно обойтись более грубой настройкой. Просто в INIT-формы запускать метод, который по расставленным для данного пользователя "флагам" сделает доступными или не доступными ряд объектов. Т.е. "в лоб" перечислить в этом методе все объекты формы доступность которых надо уточнить.

Теперь, как собственно выполняется сама проверка.

Простейший вариант - это одна таблица с кучей логических полей. Каждое поле отвечает за какое-то одно право данного пользователя.

Опять же, простейший вариант, при старте приложения просто открываешь эту таблицу прав и устанавливаешь указатель записи на нужную запись. Далее, когда нужно будет узнать права данного пользователя просто считываешь значение нужного поля из текущей записи этой таблицы.

Лучше, конечно, "обернуть" факт считывания в отдельную функцию, точнее, метод глобального класса. Чтобы не держать таблицу настроек постоянно открытой, можно скопировать все эти настройки в свойства этого настроечного класса.

Этот класс даст большую гибкость при создании приложения.

===========================

Но, вообще-то, прежде чем браться за все это необходимо просто на бумаге расписать, что именно подразумевается под "разными правами".

Может, во всех этих "наворотах" нет осообой необходимости, если у тебя, скажем, под правами понимается деление "Все только чтение / все только просмотр". Т.е. если нет "тонкой" настройки вроде: можно все, кроме ...

Krushinskaya Olgaа если идет деление по записям. Одни записи должен просматривать только этот отдел. Другие только другой. И так во всех таблицах и справочниках.
Чтобы фильтровать записи, должен существовать какой-то признак у этих записей. Т.е. некое поле, содержащее какую-то служебную информацию.

Ну, например, фильтрация по отделам. Это значит, что при выполнении запроса к таблицам, содержащим ссылку на отдел необходимо автоматически подключать к ней фильтр. Другими словами, список отделов, доступных для данного пользователя. Если для пользователя есть список доступных отделов, то это будет что-то вроде условия:

SELECT...
WHERE ...
AND otdelId IN (SELECT otdelId FROM RecordSecurity WHERE UserId="Пользователь")

Возможно, проще будет накладывать фильтр уже на результаты выборки. Т.е. выборка без ограничений, а потом SET FILTER на результат.

Здесь я не вижу простого решения. Все будет достаточно сложно.

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

Krushinskaya OlgaРебята, а еще такой вопрос.
Меня заставляют сделать этот комплекс за считанные дни - примерно за 2 недели.
Не реальные сроки для любой программы, если разрабатывать с нуля.

Krushinskaya OlgaГде можно выкопать документацию, или стандарты, сколько необходимо времени для создания клиент-серверного программного продукта?
Сомневаюсь, что такое вообще есть. Это все-равно что искать стандарт на написание рассказа или повести. Пока еще программирование - это достаточно творческий процесс. Т.е. задать жесткие рамки достаточно проблематично.

Но можешь начать вот с этого


По ГОСТ 19.201-78, ГОСТ 19.202-78, ГОСТ 19.402-78,ГОСТ 19.502-78, РД 50-34.698-90, ГОСТ 19.301-79 к программе должны прилогаться следующие документы:

Описание применения
Описание программы
Программа и методика испытаний (в случае, если предусмотрена сдача-приемка или сертификация программы)
Руководство пользователя
Спецификация
Техническое задание


Поищи эти ГОСТ-ы в интернете.

Попроси заказчика сначала предоставить хотя бы тех. задание на то, что они хотят получить. Думаю, у них уйдет как раз 2 недели, чтобы понять, а что от них вообще требуется. И при этом, само тех.задание они, скорее всего, вообще не смогут написать.

Ну, о каких обоснованиях может идти речь? Тут все очень индивидуально.

Если есть готовый класс (или набор классов) справочника, то можно лепить по справочнику в 5 минут.

Если же надо разрабатывать класс с нуля, да еще в незнакомой технологии, то на это может уйти до нескольких месяцев.

Вообще, мне кажется, что 2 недели - это минимальный срок для того, чтобы ты сама написала ТЗ. Прежде всего для себя. После это сможешь более достоверно оценить приблизительные сроки написания программы.

Оценила? Теперь умножь это минимум на 3...4. Программисты обычно переоценивают свои силы. С учетом того, что для тебя это новая технология, возможно, понадобиться еще больше времени.