hudoi, Access - и без того развитый продукт просто он не для обывателя и требует серьёзных навыков без которых начать с ним работать практически невозможно, да и не программа это а среда разработки скорее. Вы какого развития ждете?

Михаил, можно поделится - чем он так развит, особенно в плане движка? Ну, да в 2010 наконец-то добавили триггеры, и идиотскую конструкцию с выбором в столбце, плюс, убили в ACE обновление по связи со сложным Select , а это странное ограничение размера базы в 2Гбайта, а то что даже Access 64bit очень часто орёт про недостаток памяти.... А самое важное SQL движок с 97 года не менялся. SQLite на индексах в 3-4 раза быстрее работает - это при его размерах по сравнению с Access.
Кроме среды разработки по существу ничего путного.

после этого для меня он сдох. Что жто за СУБД (БД), у меня оперативки на телефоне больше. Excel, как не странно работает с большими объемами инфо, хоть и не СУБД, а табличка.
И начинать работать нет смысла, упретесь в память, еще и время потратите на переход на другую СУБД.
Уже обсуждали.

а не надо все яйца в одной корзине ( все данные в одном файле)
Примечание: Это ограничение можно обойти, создав связи с таблицами из других баз данных Access. Вы можете создать связи с таблицами из нескольких файлов баз данных, максимальный размер каждого из которых составляет 2 ГБ.  
Да и в целом надо  разносить блок с формами и кодом и с данными.

- это уже хоть что-то
НО соглашусь с тем, что как раз среда разработки очень удобная - удобнее, чем SQLite... имхо
ну ведь не для этого он создавался - да хотя бы потому, что ставится на простой HDD, а не серверный... всё-таки база данных и сервер - это понятия немного из разных плоскостей...
разве что проблема у Access со скоростью  сортировки были - но решили в соседней ветке - #118 и #143

ничто не мешает вести кадры, бухгалтерию и налоги в разных бд... да и смешивать всё в кучу - смысла нет...
ну не нужны ИПшникам такие объёмы запросов (если не лить воду в эту бд), а только FactTable (нет у них больших оборотов) и несколько InfoTbls
p.s.
даже Аналитика им не нужна во всех разрезах, только текущие поставщики и много работы offline по поиску выгодной локации, продвижению брэнда и расчётов с поставщиками... НО 80% товара выставляется на полки только для заполняемости торговой площади,  мерчендайзерам работу дают, реальный спрос лишь 20% условно - вот и раздувают такие торговые точки = для рабочих мест и красивого оформления... обороты небольшие!.. а увеличение оборотов уж совсем не количеством предоставляемых товаров достигается, когда выставляют хлам в разных упаковках, а реальным спросом на заполнение реальных нужд и потребностей спроса - их не много... время однако - спрос не успевает хотеть многого и лишнего - когда сам даже производить не успевает (= просто не производит) нужное...

не нуждалась... убираю годовую историю... справочники не трогаю... fact_table веду сначала... (не кадры и бухгалтерия - это привела в качестве примера ипшного - не разрабатывала такую бд)
не вижу проблем в UFах иметь путь до дб для выгрузки нужных отчётов, формируемых запросами

это уже др. история... не юзерская, а developer'a ... да и как правило, текущие изменения историческим данным фиолетовы - в рабочем аспекте ... имхо... или вводятся, как update, а не как "всё сломать и сделать сначала"...
а выгрузку отчетных данных даже за несколько периодов всё равно можно append'ить...

для аналитики Excel... или вести её в отдельной бд, периодически дообновляя текущие данные (хотя у меня она тоже много места не занимает - по нужным измерениям, и находится в основной бд)
никогда не рассматривала такое... разумная декомпозиция - всегда во благо, без этого никак... -- даже в 1C
не писала такого - нет необходимости, когда справочники всегда при рабочей бд (кстати вопрос хлама актуален и здесь, историю в историю и в архив лишь для истории)... вы встаньте на место ип и поймёте, что у вас не так уж много рабочих контактов будет (сведения о которых имеют право попасть в бд - т.е. реал. поставщики и взаиморасчёты с ними) - явно не на 1 гб... намного больше др. рутинной работы
изменить путь в text/list-box'e в UF - и снова прогнать запрос, чтобы до-append'ить в отчёт, если надо, - когда это надо совсем уж НЕ часто -- не занимает много времени...
p.s.
я всё-таки придерживаюсь логики соизмеримости бизнеса и бд... никто не говорит, что SQL Server не надо... он нужен только тогда, когда он, действительно, нужен, исходя из объёмов... но до объёмов на 1гб в реальном секторе экономики, а не виртуальном ещё дорасти надо - и сделать это надо в profit, а не в debt... в debt и космодром строить можно - но не рентабельно... предлагаю, не отрывать реальные потребности бизнеса от его IT-обеспечения и самим не отрываться от реалий бизнеса... чтобы хоть как-то порождать рентабельность, а не вечно растущий debt, не обслуживающий своим ростом даже спрос
p.p.s.
а то виртуально можно любой товар в любом количестве наштамповать в бд... а вот реально его реализовать, чтобы по нему зафиксировать движение в бд, - это совсем др. вопрос... и зависит от вида товара - не все группы товаров торгуются так же бойко, как продукты питания в гастрономах...
и Access'а бывает предостаточно для малого бизнеса... особенно сферы услуг, не товаров...
и он очень удобен