По сабжу - я использовал многопоточность в Access :)

По вопросу - сделать можно 2 способами:
1. Чистый WIN API: создается GUI-поток, из потока создается окно и все необходимые элементы на нем, всё на чистом API.
2. .NET: создается COM DLL, включающая в себя код по созданию потоков и окон (форм), dll цепляется к Access и дергается из кода.

Первый вариант не требует своих или сторонних DLL, но крайне некомфортен в разработке и поддержке. Второй вариант удобен, но будет подгружать в процесс Access еще и среду выполнения NET. Оба варианта тестил, фактически использовал второй. Теоретически возможен вариант VB6 COM DLL, но я не пробовал.

Мысли об использовании в режиме многопоточности форм Access, о параллельном выполнении запросов и кода нужно отбросить - даже если при неких условиях это будет работать, то любое изменение среды приведет к сбоям.
Дело в том, что 1) с окнами можно работать только из потока, который его создал, и все другие потоки могут только отправлять окну сообщения, которые будут обработаны когда поток, породивший окно, не занят, и 2) Access однопоточен (технически это не так, но в данном случае не суть), а значит код и работа с окнами ведется в одном потоке. В VBA есть единственное штатное средство "управления" рабочим потоком - команда DoEvents, которая приостанавливает обработку потоком VBA-кода и переключает поток на обработку накопившихся оконных сообщений.
Когда речь заходит о многопоточности, то обычно в простейшем общем случае речь о GUI-потоке (окна, формы) и рабочем потоке (ресурсоёмкая работа), где рабочий поток делает то, что нужно, а GUI-поток общается с пользователем. В Access такой подход невозможен, поскольку и GUI-поток и "рабочий" (VBA) поток крутятся в одном потоке и разделить их невозможно, во всяком случае ни у меня, ни у людей в инете не получилось. Да такое "разделение" чревато проблемами в новых версиях офиса.
В итоге, единственное что остается, это добавить в Access еще один (или несколько) GUI-потоков, которые будут общаться с пользователем, пока Access занят ресурсоёмкой работой. Окна, созданные в этом дополнительном GUI-потоке могут быть как обособленными, так и встраиваемыми в Access-формы в качестве чилд-форм, но (и это важно), они не могут быть формами Access, т.е. должны создаваться либо через WIN API, либо через .NET.
Ключевой момент здесь в том, что Access ничего не должен знать о замышленной вами многопоточности, обращаться из "нелегального" потока можно только к [желательно глобальным] переменным с простым типом данных; никакие объекты, тем более объекты Access (формы, рекордсеты и т.п., хотя это отдельная тема) даже читать нельзя, не то что как-то их менять.
Не теряйте время на попытки использовать формы Access в режиме многопоточности - это концептуально/архитектурно неправильно, но дополнить независимые от Access окна/формы вполне возможно и работает стабильно.

Joss,

о статье Эпплмана:
васик и аксес - это очень разные вещи и в плане многопоточности аксес сильно сложнее, запутанней, поскольку если в дела программиста (ход выполнения программы) чуть-чуть влазит с отсебятиной VB, то в Access все наоборот - в дела Access чуть-чуть с отсебятиной (код VBA) влазит программист.

о примере в "ad_SimpleMultithreading.rar":
он работает без падений только потому, что в процедуре, выполняемой в "искусственном" потоке есть только работа с переменными простых типов, прям как я сказал: "обращаться из нелегального потока можно только к [желательно глобальным] переменным с простым типом данных". Этот код можно использовать исключительно в демонстрационных целях, поскольку придумать прикладную задачу в Access, которая не использовала бы объекты БД, лично я не в состоянии.

о примере в "Potoki.rar":
запуск базы завершился крашем (см.аттач). И если почитать меня ("с окнами можно работать только из потока, который его создал" и "никакие объекты, тем более объекты Access (формы...) даже читать нельзя, не то что как-то их менять"), а так же MS (гуглить по "Потокобезопасные вызовы windows" и "Invoke"), то становится понятно, что нельзя из потока, не породившего окно, пытаться лезть к этому окну, что и происходит в процедурах "искусственных" потоков этой БД - там есть обращение к форме и контролам на ней.

Попытки обратиться к формам (окнам) из "искусственного" потока завершатся крашем, поскольку так делать нельзя на уровне ОС (!), попытки обратиться к другим объектам Access из "другого" потока тоже ничего хорошего не сулят.. так, например, DAO однопоточен по природе своей и попытка из созданного вами потока обратиться к рекордсету тоже приведет к крашу (хотя другим способом вполне можно выполнять и запросы в нескольких потоках).

Архитектурно верное (проверенное и работающее) направление в рамках Access я указал. Лично я уверен, что это единственное более-менее надежное решение, но, как говорится, кто знает)

Joss, на Win 7 32bit и Win 8 64bit под Access 2013 база Potoiki стабильно падает. Почти всегда падает сразу же, несколько раз прогресбар успевал пробежать на 1/3. Если заремить обращения к контролам, то все отрабатывает стабильно, хоть визуально и ничего не происходит. Других версий офиса под руками нет, поэтому ничего не скажу за А2007.

Можно пытаться шаманить, но, ИМХО, не в этом случае. Я повторюсь, но дело даже не в аксесе, а в операционке - нельзя в Windows обращаться к окнам из не создавших их потоков. Это не зависит от языка или среды разработки/выполнения, это зависит именно от ОС - не разрешает она этого делать. Первая попавшаяся ссылка на эту тему, можно погуглить еще:
https://msdn.microsoft.com/library/ms171728(v=vs.100).aspx?cs-save-lang=1&cs-lang=cpp#code-snippet-1 Access to Windows Forms controls is not inherently thread safe. If you have two or more threads manipulating the state of a control, it is possible to force the control into an inconsistent state. Other thread-related bugs are possible, such as race conditions and deadlocks. It is important to make sure that access to your controls is performed in a thread-safe way.
It is unsafe to call a control from a thread other than the one that created the control without using the Invoke method. The following is an example of a call that is not thread safe. bla-bla-bla...
Почему вы не хотите задействовать собственную dll на основе .NET? Разработка комфортна, появляющиеся возможности практически безграничны.. В рамках хобби я начинал делать библиотеку, позволяющую делать в Access нереальные для него вещи. Например, мне было интересно создать самописный грид, в котором я использовал 3 потока: первый читал данные в массив, второй выполнял преформатирование, в т.ч. условное, третий отрисовывал на экран, и при этом всём поток Access (единственный и основной) мог заниматься чем угодно, поскольку не использовался в работе грида вообще. Т.е. используя эту технологию вы можете не то что прогресбар отрисовать, но и делать многое прочее.. и все это в архитектурно и концептуально корректных рамках (речь о технической стороне вопроса, не о безумной), т.е. не будет зависеть от версии ОС или Access.

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

Joss, к сожалению готового решения у меня нет. Но если бы я был на вашем месте, то во-первых я бы подумал о штатных средствах (разбить длинную задачу на подзадачи, между которыми сообщать пользователю, что процесс идет) и только потом попробовал бы отрисовку на форме средствами WinAPI. DLL-ки, особенно на базе .NET, не использовал бы - в данном случае это из пушки по воробьям.

Уверен, что штатные средства/возможности Access вы знаете лучше меня, поэтому даже не буду их обсуждать. Что касается отрисовки из другого потока, то я бы:
1) Почитал бы про отрисовку средствами WinAPI/GDI из потока, не являющегося владельцем окна, например (первая попавшаяся ссылка) это: http://enginecore.blogspot.ru/2007/02/threading-on-gdi-objects.html ........... Device contexts (DCs) also have a certain degree of thread affinity. The thread that calls functions such as GetDC must also be the one that calls ReleaseDC, but as with window handles, during the lifetime of the DC, any thread can use it, but one at a time. If you choose to use a DC in a multi-threaded manner, it's your responsibility to coordinate the consumers of that device context so that only one thread uses it at a time.........2) Нашел бы адаптированные под Access примеры рисования средствами GDI (я видел какие-то часы и градиентные заливки, примеров довольно много)

3) Перед запуском "длинной" задачи открыл бы форму с пустым фоном, получил бы ее контекст устройства (GetDC) и из "искусственного" потока по WinAPI-таймеру (таймер формы использовать нельзя) рисовал бы в этом контексте что-нибудь простенькое. Скорее всего тупо заливал бы градиентной заливкой со смещением цвета, чтобы по форме шла цветная волна - и просто в реализации, и пользователи будут запускать задачу снова и снова, чтобы вштырило еще раз :) Хотя можно и что-то более сложное, но париться с анимированными GIF я бы не стал - слишком сложно реализовать "руками". Никакие контролы/компонетны на форме использовать нельзя - можно только рисовать через GDI в контексте устройства окна формы.
Из "искусственного" потока можно читать какие-нибудь глобальные переменные, чтобы следить, что процесс действительно идет, но обращаться к объектам нельзя.

4) Разобрался бы с корректным завершением потока (в свое время так и не удалось этого сделать, в итоге использовал потоки, созданные через мою .NET-dll - там они корректно создаются и уничтожаются)

5) Посмотрел бы на это всё и, получив ценный опыт, либо вернулся бы к штатным средствам Access, либо доделал бы уже dll, добавив себе возможность использовать "нереальные для Access" плюшки :)

P.S. Понимаю, что мало чем помог, но надеюсь что все же помог хоть чем-то..

Стоп. Таймер использовать тоже нельзя :) Вместо таймера я бы делал Sleep искусственному потоку на нужное время. Да, через Sleep)