Търсих MSDN и няколко други форума на Access за създаване на персонализирани API за достъп, но не видях нищо свързано. Това възможно ли е? Могат ли да се създават персонализирани ODBC за Access?
Мога ли да създам персонализиран MS-Access API за интерфейс с други приложения?
Отговори (1)
Хм, това е объркващо, тъй като не е ясно дали говорите за изграждане на интерфейси с Access към ДРУГИ системи, или говорите за изграждане на интерфейс на Access, който други програми могат да използват?
ODBC е "драйвер", предоставен от доставчиците, за да позволи използването на техните системи за бази данни SQL и е нещо, което не създавате в Access или FoxPro или във VB по този въпрос. Всъщност не мога да се сетя за инструмент, ориентиран към данни, който би ви позволил да създадете свой собствен ODBC драйвер. Така че това предполага известно объркване тук.
Разширяване на достъпа.
Access през последните 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 (com обекти), но със сигурност може да използва такива, които създавате на други езици.
ЗАБЕЛЕЖКА: Тук използвам термина взаимозаменяемост на ActiveX и „COM обект“ – те са една и съща основна технология.
Така че, ако някога сте използвали настолен компютър и който и да е инструмент за разработка на Windows, установявате, че "COM" обектите са изборът и ОСТАВАТ избора как да разширите Access или дори този на VB6. С управлявания код нещата се променят донякъде, но vb.net е доста щастлив да създава COM обекти, които работят добре с Access.
Докато Access не може като инструмент да създава ActiveX (com) обекти, вие със сигурност можете да компилирате код на Access в accDE и СЛЕД това да препратите към този библиотечен код от VBA tools->references. Така че можете да разширявате и споделяте VBA код в една библиотека с "много" приложения, но това не е com обект.
Така че точно както в миналото за разширяване на настолни програми, можете да създавате такива разширения като COM обекти и да ги консумирате от Access – това е стандартният подход за разширяване на Access, за да кажем, че консумирате уеб услуги.
Access не може да се използва за изграждане на отделни COM обекти като части на потребителския интерфейс, но СТАНДАРТНОТО средство в нашата индустрия за създаване на COM обекти може да се използва от Access.
Не на последно място: Всяко приложение, което създавате в Access, МОЖЕ ДА СЕ КОНСУМИРА като COM обект от други приложения. Така че докато не можете да създавате отделни COM обекти, ЦЯЛОТО ви приложение всъщност е com обект.
Така че, ако изградите приложение в Access, тогава използвате Excel, VB6, FoxPro, друго приложение на Access, C++ или C# или vb.net? Те ВСИЧКИ МОГАТ да използват вашето приложение като com обект, като просто създадат екземпляр на Access и вашето приложение.
Така че всеки инструмент за разработка, който поддържа "com", може да използва вашето приложение като com обект. Така всеки стандартен инструмент за разработка, статия или система за последните 20 години може да използва вашето приложение на Access като COM обект.
Така че докато Access не може да създава индивидуални COM обекти, получените приложения на Access всъщност са легални com обекти, които ВСЯКО приложение, което поддържа COM, може да създаде екземпляр на вашето приложение. Това означава, че вашият код и VBA subruties и т.н. могат да бъдат извикани от хост приложението, което е създало екземпляра на вашето приложение. На теория всеки VBA код, изложен като "публичен код", може да бъде извикан от тази друга програма.
Така че „интерфейсите“, достъпни за Access, остават СЪЩИТЕ като почти 20-годишната история на ПОВЕЧЕТО настолни програми, работещи на Windows – този интерфейс е COM.
Така че имате 20 години история и 20 години примери в интернет, с които да се забавлявате - всеки пример, който показва как да създадете и консумирате com обект, трябва да работи за вашето приложение за достъп.
person
Albert D. Kallal
schedule
16.02.2014
Отдавна не съм те чувал. Моля, изпратете ми вашия имейл за връзка за нещо друго. Що се отнася до моя въпрос тук, способността на Access да се интегрира/комуникира с други приложения чрез API, освен ODBC и OLEDB, тъй като не всяко друго приложение има такива! Пример е този друг въпрос. Какво да използвам в края на Access 2013/SQL-Server, за да извличам и съхранявам съдържание от този dropbox?
- person Frank R.; 17.02.2014
Вие просто ще разширите Access, като използвате COM, за да използвате тази уеб услуга. Защо просто не синхронизирате локалната папка и след това използвате стандартните DIR и файлови команди, които съществуват във VBA и след това не са необходими извиквания на уеб услуги? Drop box по някаква странна причина НЕ разполага с изложена WSDL уеб услуга. Въпреки това, докато никоя уеб услуга не е изложена, те излагат функции чрез HTTP. Така че можете лесно да напишете свои собствени оператори get и put: от Access (просто използвайте библиотеката MSXML, тъй като тя поддържа get/puts). Така че двете решения, които предложих тук за използване на уеб услуги в Access, се прилагат 100% за използването на падаща кутия.
- person Albert D. Kallal; 18.02.2014
В API на Box забелязах Windows API и SDK за разработване на персонализирани API. Но моят потребител е по-заинтересован от интегрирането на тяхното приложение Access 2013 с приложението за управление на случаи на техния клиент, също разработено с Access 2007. Така че ODBC ли е най-добрият начин да отидете с Access to Access или COM все още е по-добрият избор? Казах на потребителя си, че е най-добре да автоматизира кутията към тях и тях към клиента, така че да не се налага да преместват съдържанието ръчно.
- person Frank R.; 18.02.2014
можеш ли да се присъединиш към мен в чат? Опитвам се да се свържа с вас относно моето управление на заложна къща. Приложение
- person Frank R.; 18.02.2014
Защо да се занимавате с уеб API, когато всичко, от което се нуждаете/искате, е локалните файлове на вашия компютър да бъдат обработени? VBA има всички команди за хващане + изтегляне на файлове от локална папка. Така че защо просто не синхронизирате с локална папка и след това използвате обикновен Jane VBA, за да обработите тези входящи файлове с Access. В момента използвам падаща кутия с Access и обработваме 100 входящи pdf файлове на ден по този начин. Така че синхронизирайте с локална папка и след това просто използвайте VBA - не се изисква уеб API. Виждам малка причина да използвате уеб API, но използването на MSXML с Access вероятно е най-добрият начин, ако искате да използвате уеб API.
- person Albert D. Kallal; 18.02.2014
И не, ODBC няма да помогне, тъй като падащата кутия няма ODBC връзка или интерфейс. Така че, както беше отбелязано, трябва да използвате нещо, което ви позволява да консумирате данни от уеб сайта - MSXML библиотеката е един такъв com обект, ако по някаква причина синхронизирането с локална папка и просто използването на собствени VBA команди за изваждане и обработка на файлове в тази папка ще не е достатъчно.
- person Albert D. Kallal; 18.02.2014
Има една папка в падаща кутия, която получава всички PDF документи за нашите ~120 клиенти. След това ръчно разпространяваме тези документи до ~120 папки в нашата система, изпращаме имейл известия до нашите клиенти, че имат нови документи в папката си, те влизат в нас и извличат документите от своята папка. И така, как да автоматизирам това с помощта на VBA, за да разпределя правилно документите в съответните потребителски папки в нашата система? Същият въпрос се отнася за препращането на документите към приложението Access на всеки клиент.
- person Frank R.; 18.02.2014
Ако просто синхронизирате и вземете документа или като алтернатива използвате уеб услугата, за да изтеглите документа, тогава в този момент имате план Jane документ на вашия локален диск, който Access може да обработи. Така че синхронизирането или уеб услугата не означават, че имате прикачена информация за клиента към този документ. НАИСТИНА е по-добре да проверите дали уеб API дава тази информация, тъй като не е даденост. Ако нямате прикачена информация за клиента, когато вземете този документ, тогава не е възможно автоматизирано маршрутизиране. Трябва да приемете отделни входящи папки за всеки клиент или да използвате конвенция за именуване на файлове.
- person Albert D. Kallal; 19.02.2014
Access.Applicationобект). Ако имате предвид някакъв конкретен случай на използване, който не е обхванат от тези опции, моля, редактирайте въпроса си, за да го уточните. По същия начин, моля, обяснете какво имате предвид под персонализиран ODBC ... за Access. - person Gord Thompson schedule 16.02.2014