Могу ли я создать собственный API MS-Access для взаимодействия с другими приложениями?

Хм, это сбивает с толку, поскольку неясно, говорите ли вы о создании интерфейсов с доступом к ДРУГИМ системам, или вы говорите о создании интерфейса доступа, который могут использовать другие программы?

ODBC — это «драйвер», предоставляемый поставщиками для использования их систем баз данных SQL, и это то, что вы не создаете в Access, FoxPro или в VB, если уж на то пошло. На самом деле я не могу придумать ни одного ориентированного на данные инструмента, который позволил бы вам создать собственный драйвер ODBC. Так что это предполагает некоторую путаницу здесь.

Расширение доступа.

Доступ в течение последних 20 лет имел возможность использовать ActiveX (объекты COM). Таким образом, то, как можно расширить возможности Access для взаимодействия с другим программным обеспечением и системами, ОСТАЕТСЯ выбором COM-объекта. Так, например, можно использовать библиотеку MSXML из Access (объект COM), и это позволяет использовать веб-страницы и указывать XML, который открывает дверь для использования веб-служб. На самом деле я использовал MSXML, например, для использования веб-служб SharePoint.

Однако для использования веб-служб обычно гораздо лучше создавать COM-объект с инструментами, которые могут «уже» использовать веб-службы. Таким образом, можно использовать vb.net для создания COM-объекта, а ЗАТЕМ ссылаться на этот COM-объект из MS Access (так же, как мы устанавливаем ссылку на Outlook или Word из Access, такие COM-объекты не ограничиваются приобретенными вами приложениями, но вы наиболее свободно создавать свои собственные COM-объекты VB6, vb.net, C # или что-то еще).

Access НЕ имеет возможности создавать ActiveX (ком-объекты), но он, безусловно, может использовать те, которые вы создаете на других языках.

ПРИМЕЧАНИЕ. Здесь я использую взаимозаменяемость терминов ActiveX и «COM-объект» — это одна и та же базовая технология.

Итак, если вы когда-либо использовали настольный компьютер и какой-либо инструмент разработки Windows, вы обнаружите, что объекты COM являются выбором и ОСТАЮТСЯ выбором того, как расширить доступ или даже VB6. С управляемым кодом все несколько меняется, но vb.net вполне может создавать COM-объекты, которые хорошо работают с Access.

Хотя Access не может в качестве инструмента создавать объекты ActiveX (com), вы, безусловно, можете скомпилировать код Access в accDE и ЗАТЕМ ссылаться на этот код библиотеки из инструментов VBA->references. Таким образом, вы можете расширять и совместно использовать код VBA в одной библиотеке со «многими» приложениями, но это не объект com.

Таким образом, как и в прошлом для расширения настольных программ, вы можете создавать такие расширения как COM-объекты и использовать их из Access — это стандартный подход к расширению Access для использования веб-сервисов.

Access нельзя использовать для создания отдельных COM-объектов в качестве частей пользовательского интерфейса, но СТАНДАРТНЫЕ средства в нашей отрасли для создания COM-объектов могут использоваться Access.

И последнее, но не менее важное: любое приложение, которое вы создаете в Access, МОЖЕТ БЫТЬ ПОТРЕБЛЕНО как COM-объект другими приложениями. Таким образом, хотя вы не можете создавать отдельные COM-объекты, ваше приложение ПОЛНОСТЬЮ на самом деле является COM-объектом.

Итак, если вы создаете приложение в Access, а затем используете Excel, VB6, FoxPro, другое приложение Access, C++, C# или vb.net? Они ВСЕ МОГУТ потреблять ваше приложение как ком-объект, просто создавая экземпляр Access и ваше приложение.

Таким образом, любой инструмент разработки, поддерживающий «com», может использовать ваше приложение как объект com. Таким образом, любое стандартное средство разработки, статья или система за последние 20 лет могут использовать ваше приложение Access как COM-объект.

Таким образом, хотя Access не может создавать отдельные COM-объекты, результирующие приложения Access фактически являются законными COM-объектами, и ЛЮБОЕ приложение, поддерживающее COM, может создать экземпляр вашего приложения. Это означает, что ваш код, подпрограммы VBA и т. д. можно вызывать из основного приложения, которое создало экземпляр вашего приложения. Таким образом, теоретически любой код VBA, представленный как «общедоступный код», может быть вызван из этой другой программы.

Таким образом, «интерфейсы», доступные для Access, остаются ТАКИМИ ЖЕ, что и почти 20-летняя история БОЛЬШИНСТВА настольных программ, работающих в Windows — этот интерфейс — COM.

Итак, у вас есть 20 лет истории и 20 лет примеров в Интернете, с которыми можно повеселиться — любой пример, показывающий, как создавать и использовать com-объект, должен работать для вашего приложения доступа.