Ad-hoc низове за свързване и хетерогенни заявки за MS Access
Хетерогенните заявки са причината низовете за връзка, особено ad-hoc низовете за връзка, да са важни. В предишни статии от поредицата видяхте как можете да персонализирате параметрите на връзката за свързване с Excel и текстови файлове. В случай на текстови файлове можете също да опишете схемата на структурата на текстовия файл с помощта на schema.ini
или запазени спецификации. В първата статия научихте и разликата между свързването и отварянето на източник на данни.
Хетерогенни заявки вместо VBA код
Видяхте в предишните статии примерен код за отваряне на такъв източник на данни с помощта на OpenDatabase
на DAO метод.
Set db = DBEngine.OpenDatabase(vbNullString, False, False, "Excel 12.0 Xml;HDR=YES;IMEX=2;ACCDB=YES;DATABASE=C:\Links\Products.xlsx")
Това може да ви остави с впечатлението, че единственият начин да отворите източник на данни е чрез код. Но това не трябва да е така! Всъщност можете да отворите произволен източник на данни, като използвате само заявка за Access. Ето примерен синтаксис, който можете да изпълните в заявка за Access:
SELECT * FROM [Excel 12.0 Xml;HDR=YES;IMEX=2;ACCDB=YES;DATABASE=C:\Links\Products.xlsx].[Sheet1$];
Най-общо казано, низът за връзка, който сте поставили в OpenDatabase
Четвъртият параметър е този, с който ще поставите префикс към „таблицата“. Следователно общият синтаксис би бил:
FROM [<complete connection string>].[<name of the table>]
Можете да използвате OpenDatabase
метод и повторете над TableDefs
за да намерите валидните имена на таблицата. След това можете да го използвате, за да попълните 2-ра част от името.
Защо отваряне вместо връзка?
Едно предимство на отварянето в сравнение с свързването е, че можете да промените низа за връзка по време на изпълнение. Освен това не е нужно да се занимавате с необходимото почистване, като например изтриване на вече ненужни свързани обекти. Това е чисто преходно, което би било идеално за преместване на данни от един източник в друг източник, без да се пише VBA код.
Ето един възможен сценарий. Да предположим, че искаме да създадем текстови файлове, които са изход от изглед на нашата база данни на SQL Server. Видяхте от предишни статии, че можем да напишем VBA код, който да обикаля наборите от записи на DAO и да пише съдържанието един по един. Като алтернатива обаче можем просто да създадем заявка за Access с този SQL:
INSERT INTO [Text;DATABASE=C:\Links\].[products.csv;] (Products, Count) SELECT Products, Count FROM [ODBC;DRIVER=ODBC Driver 17 for SQL Server;SERVER=myServer;DATABASE=myDatabase;].[vwProducts];
Тъй като и местоназначението, и източникът не са източник на Access, това е това, което наричаме „хетерогенна заявка“. Имайте предвид, че дори ако vwProducts
е свързана таблица, тя пак ще бъде „хетерогенна“ заявка. Това е така, защото все още смесваме различни източници на данни в една заявка.
По-важното е, че използвайки хетерогенна заявка, ние избягваме необходимостта от създаване на временни обекти в нашето приложение Access. Създаването на временен обект може да доведе до раздуване на приложението Access. Това е така дори при импортиране или чрез свързване или чрез използване на набори от записи във VBA. Раздутият файл може от своя страна да изисква уплътняване и поправка. Въпреки това, когато използвате хетерогенна заявка за директно прехвърляне на данни от един източник на данни към друг, избягвате цялото това подуване. Следователно, това го прави идеален за сценарии, при които вашето приложение Access трябва да генерира няколко файла без поддръжка на самото приложение.
Изграждане на ad-hoc низ за връзка
Вече можете да разберете защо е ценно да разберете параметрите, използвани в низа за връзка. Особено важно е да контролирате дестинацията (например път за текстови файлове или диапазон за листа на Excel). При тези нерелационни източници на данни това, което представлява „база данни“ и „таблици“ в такъв източник на данни, може да не е интуитивно. Можете да използвате последните 3 статии като справка за помощ при конструирането на низа за връзка и информацията за схемата, за да сте сигурни, че оформлението е правилно. Въпреки това има и пряк път, който можете да използвате, за да ви помогне да намерите низа за връзка.
Можете да използвате раздела Външен и или „Импортиране на текст“ или Импортиране на Excel“ и да изберете опцията за връзка. Обикновено това е третата опция на съветника, както е показано.
След като преминете през съветника и запазите новата свързана таблица, можете да проверите низа за връзка чрез непосредствения прозорец на VBA с този код:
?CurrentDb.TableDefs("<name of linked table>").Connect
Това може да ви даде съвети как да изградите низа за връзка и след това можете да персонализирате. През повечето време ще се окажете, че персонализирате пътя или името на таблицата, така че обикновено да работи достатъчно като техника по време на вашата разработка. След това можете да създадете съответно хетерогенна заявка и да изтриете свързаната таблица.
Заключения
В поредицата научихте разликата между свързване и отваряне. След това видяхте как Excel и текстовите файлове могат да се използват, сякаш са DAO.Database
обекти с „таблици“. С втората статия научихте за параметрите на връзката за работна книга на Excel. В 3-та статия видяхте нуждата от информация за схемата, за да опишете текстов файл. Четвъртата статия описва как да използвате schema.ini
. В 5-та статия видяхте как MSysIMEXSpecs
и MSysIMEXColumns
може да се използва като алтернатива на schema.ini
метод.
И накрая, ние обединяваме всичко в конструирането на хетерогенна заявка като пример за решение с нисък код. Не е нужно да пишем голямо количество VBA код, само за да прокараме данни от един източник към друг източник. Мисля, че ще се съгласите, че е много по-лесно да модифицирате заявка на Access чрез коригиране на пътя или името на таблицата, отколкото да напишете голяма и сложна VBA рутина за четене и запис на данни. По-важното е, че чрез използване на хетерогенна заявка става много по-лесно да се справят с промените в структурата от двете страни. Добавена ли е нова колона? Няма проблем, просто добавете новата колона към заявката и сме готови.
Въпреки това, както виждате, това изисква добро разбиране на конструкцията на низа за свързване. Поради тази причина беше необходимо да се проучат в дълбочина тънкостите на низа за свързване, както направихме от 2-ра до 5-та статия. Въпреки че можем да използваме съветника за свързана таблица, за да ни даде намек за низовете за връзка. Но това са само намеци. Затова е добре да знаете как точно да контролирате изхода. Надявам се, че сте съгласни, че инвестирането на някои усилия в разбирането как работят низовете за връзка ще се изплати със спестен труд.