Добрый день/ночь/утро/вечер.

Попробую сформулировать вопрос максимально точно. Если будет не понятно, пожалуйста уточняйте.

Итак... Есть один mdb файл в котором есть очень много форм, таблиц, модулей и т.п. Хотелось бы разделить этот файл на функциональные mdb файлы. Например: в первый файл вынести работу с накладными, во второй работу с зарплатой, в третий работу с движением денежных средств, в четвертый справочники и т.п. Все эти "модули" взаимосвязаны между собой. Например: справочник товаров будет использоваться и в модуле работы с накладными, и в модуле отчетов, и в модуле планирования. Причем во всех модулях должна использоваться одна форма на добавление/редактирование товара. Поэтому и хочется выделить форму создания/редактирования товара в отдельный файл mdb что бы делать изменения в одном месте, но при этом иметь возможность вызывать эту форму во всех остальных модулях.

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

Примерно так: Есть файл mdb в котором содержаться формы по работе с накладными - назовем его модуль накладных. Есть файл mdb к которому с помощью References подключен модуль накладных. назовем этот файл основным модулем. Так вот. Когда из из основного модуля вызывается форма, которая находиться в модуле накладных, а потом на форме нажимается кнопка которая запускает запрос DoCmd.RunSQL "Select * INTO Table_tmp From Table ", то таблица Table_tmp создается в основном модуле, при этом таблица Table - также используется из основного модуля. А хотелось бы что бы эти таблицы оставались "жить и функционировать" в модуле накладных. Я конечно могу заставить все запросы работать по принципу "Select * INTO Table_tmp IN "модуль накладных" FROM Table IN "Модуль накладных" - но как-то коряво .... Чувствую что должно быть более элегантное решение :( но где копать не знаю... Лопатой я уже вооружился, подскажите куда на какое "поле дураков" идти, копать...

А может я вообще не в ту степь двигаюсь? Подскажите/поделитесь мыслями как правильно организовать структуру таких файлов и связей между ними ? как правильно запускать запросы? ну и т.п.

Заранее благодарен.

PS: надеюсь смог объяснить свои желания...

В принципе пока сидел ждал ответа, нашел определенное решение, которое в первом приближении меня устраивает. Для этого в процедуре в которой проводиться запуск запроса на выполнение необходимо сделать для себя ссылку на нужный функциональный модуль и запускать запрос уже с использование этой ссылки.
Примерно так:
Dim db As Database
Set db = Application.DBEngine.OpenDatabase("функциональный модуль (например: накладных) mdb")
db.Execure "Select * INTO Table_tmp FROM Table"

В этом случае в основной модуль линковать таблицы уже не надо и "временные" таблицы, которые создаются SQL-кодом "Select * INTO ... FROM ..." создаются в нужном мне модуле. Есть одно "Но!". Данный SQL-код уже не удаляет таблицу перед ее созданием, но удалить ее ручками не представляет никакой сложности
db.TableDefs.Delete "Table_tmp"
db.Execure "Select * INTO Table_tmp FROM Table"
вполне нормально работает.

И все же. Хотелось бы услышать замечания и мысли по поводу функционального разделения приложения на модули от коллег, которые пишут на MS Access.

PS: Буду благодарен всем, кто выскажет свои мысли...

Попытаюсь сразу ответить все.

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

Во-вторых. Разделение кода на разные функциональные модули связано с несколькими моментами.
20 пользователей, каждый из которых работает со своими функциональными модулями. Самих модулей тоже навскидку около 10. - На сегодня пока ничего лучше чем поделить на модули не придумал. - Если у кого-то есть идеи, буду рад выслушать.

В третьих. Использование Application.Run - возможно и неплохая вещь. Но подключение другой базы как References дает мне возможность использовать все константы, функции и процедуры подключенной mdb, что дает возможность хранить код в одном месте, а не повторять его по разным - легче проводить правку кода :)

В четвертых. Если не ошибаюсь, то использование структуры CodeProject.Connection.Execute - это ADO технология, я же пользуюсь пока старым добрым DAO :) (вот такой я пока еще динозавр)

Спасибо за подсказку про CodeDB - сейчас протестирую. Хотя если опираться на контекст написавшего сообщение Нутакэто - должно вполне подойти.

Shark>Честно говоря, пока не понятно, насколько обоснованно желание формы по работе с накладными выделять в отдельный файл mdb

+1
25мб интерфейсный файлик после сжатия у мну, вроде работает. Если вам нужна нормальная объектная модель, то лучче не изобретать велосипед с квадратными колесами, а перейти на платформу где она есть. ИМХО.

Интересно... с какого боку тут может рассматриваться "объектная модель" ?

Возьмем просто пример:
1-й пользователь (заказчик) заказывает приложение которое должно уметь выписывать накладные по приходу расходу товаров. Проходит, какой-то период и пользователь хочет основываясь на введенных накладных построить систему учета расчетов с поставщиками и покупателями. Что мы делаем по вашей "теории" ? вносим в интерфейсный файл определенный модули, формы, отчеты и т.п.
2-й пользователь работает с учетом расчетов с поставщиками и покупателями. По истечению определенного времени он просит подключить ему модуль расчета заработной платы - ок. подключаем. т.е. опять вносим модули, формы, отчет и т.п. в интерфейсный файл.

Получаем два интерфейсных файла в которых есть один и тот же код - модуль расчетов с поставщиками/покупателями.. ну и как прикажете вносить правки в такие файлы если надо исправить именно модуль расчетов с поставщиками/покупателями? исправлять в одном файле? а потом в другом?. а если таких файлов 10?.

Гораздо проще (с моей точки зрения) иметь отдельный MDB, который отвечает за расчеты с поставщиками/покупателями и максимально простой механизм его подключения для пользователя. В таком случае достаточно внести исправление в одном файле и выслать его всем пользователям кто его использует.

Или я неправ?

SharkЛучче иметь один файл и в нем всю функциональность. И отключать ее в зависимости от прав. Если ваше приложение имеет 1000+ модулей и над ним работает 3+ разработчиков, то access на мой взгляд не самый удачный выбор. Хоть бей приложение на части хоть нет. А если нет, то все и в одном файле неплохо поживет. Разумееца, имхо.
Вы так и не ответили на вопрос, зачем вам понадобился этот огород с разбиением.

На вопрос я ответил ровно на один пост выше над Вашим. Хз. Бить приложение на части или не бить - это еще тот вопрос. Мне например надоело копаться в 200+ таблицах и 200+ формах, а еще есть пачка отчетов и запросов и это не предел. Гораздо проще все это разбить на функциональные части. кроме того из таких функциональных частей гораздо проще собирать приложение на продажу. Да и доработки гораздо проще вносить в один функциональный файл mdb и отсылать его N-людям использующим приложения, чем исправлять по куче приложений. Да и размер тоже не мало важен. Я конечно понимаю что в наш век приложение в 100 Мб - этот не предел, но как-то не хочется расти до такой монстрообразности (мой поджатый интерфейсный файлик сейчас уже весит 30+Мб а еще кучу всего туда надо будет запихнуть)

В самой теме вообще не обсуждался вопрос "бить или не бить?" - спрашивалось - "как?"

В принципе ответ я получил... Ситуация с CodeDB меня вполне устраивает. Так что ....

NeboТак легче контролировать весь проект, обеспечивать согласованную работу.
А вот когда разбиваем проект на части, то уже приходится думать,
например, о правильном присоединении связанных таблиц во всех внешних модулях.


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

NeboЯ ещё, кстати, не пробовал, можно ли через Refereneces взять форму
и вставить её как субформу. Через Application.Run вроде этот фокус не проходит.
Форма открывается только как диалог.
Поэтому иногда, из-за определённой компоновки проекта,
невозможно использовать внешнюю форму через Application.Run

а смысл? используя References гораздо проще вызвать всю форму которая использует субформу. Хотя тут уже наверное от задачи зависит. Надо пробовать. Зато обычная форма нормально открывается в отличии от диалогового открытия в Application.Run

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

Ну а я держу все временные таблицы в интерфейсном файле... И пересоздаю их запросами. Ну и подумаешь что он немного пухнет... :) При следующем входе в программу специальный менеджер его успешно скопирует пользователю с сервера и запустит. - Для пользователя эта задержка в лишние 10 секунд - максимум. Для меня отсутствие проблем с обновлением версий. - бегать по 4-м этажам длиной 100 метров и обновлять клиентские части 20+ клиентам - мне влом. Гораздо проще положить новую версию в папочку на сервер и менеджер на локальной машине сам ее стянет. И эта версия будет уже поджата мной. Кроме того если где-то проморгал ошибку - процесс отката/обновления занимает минимум времени - положил старую версию на сервак - позвонил пользователям, что бы они перезашли в программу - и все. Потом исправил ошибку - положил на сервер - звякнул пользователям - и опять пришло счастье. Но это дело на любителя. Мне удобно, а кто-то такой способ может посчитать извращением.

П-ЛБлагодаря форуму узнал трюк как делать New объектам, если классы сидят в библиотеке.
Решил остаться на штатном способе через функцию из библиотеки, рекомендуемом MSDN.


Если не сложно ссылку на "трюк" и на "штатный способ" :) буду очень благодарен