Подключение odbc access

Строка подключения ODBC c параметрами

Доброго времени суток.

Делаю GUI на MS Access 2007 к базе данных MS SQL и необходима динамическая авторизация пользователей.

Т.Е. есть форма в которую пользователь вводит логинпароль, нужно их использовать в строке подключения ODBC,
причем очень хотелось бы просто конструктором сделать запрос к серверу и в строку подключения вписать введенные логин и пароль, однако:

Вот это Access кушает с удовольствием:

Пишет не правильная строка подключения ODBC

Вопрос — можно ли вообще в этой строке использовать выражения, или придется делать все на VBA?

Строка подключения ODBC
Создан ODBC источник для базы. Сама база имеет пароль. Как должна выглядеть строка подключения? .

ODBC ошибка подключения
Уважаемые знатоки, прошу помощи настроил экспорт данных с сервера MYSQL в базу данных acces, на.

Программная настройка подключения через ODBC
Здравствуйте! Имеется форма, которая получает данные из связанных таблиц посредством ODBC. Когда.

Запрс с параметрами MySQL через ODBC 5,1
Подскажите чё не так? Запрос в C# ReadCommand.CommandText = "SELECT.

Возможно я не правильно выразился, но у меня есть полностью рабочая строка подключения.

Вопрос в том как заставить Access подставлять в нее значения из TempVars.

Пока пришлось сделать на VBA вот так:

НО при выходе логин и пароль остаются в строке в открытом виде.

Можно конечно очищать ее перед закрытием или запуском Access, но было бы проще и лучше если бы там оставались только ссылки на TempVars.

Добавлено через 6 минут
PS. Имеется ввиду именно свойство «Строка подключения ODBC» в конструкторе запросов Access 2007 — можно ли там использовать выражения Access и если да, то какой синтаксис

Intervent,
я бы хранил («запоминал») такого рода данные в отдельной таблице, но уж никак не в переменных

Добавлено через 48 минут

Благодарю за ответ!

Глобальные переменные я решил использовать с той целью, чтоб в случае разрыва сессии по любой причине в Access не оставались пароль и логин в открытом виде. На сколько я понимаю эти переменные хранятся в ОЗУ, поэтому даже если кто-то получит доступ к файлу Access(в том числе во время активной сессии, через сеть напимер), логин и пароль ему все равно не достанется. Или я не прав.

Вообще суть в следующем (все на Access 2007):

Пользователь запускает файл Access , открывается форма Авторизации. Вводит логин/пароль (именно они и хранятся на время сессии в TempVars) и эти данные используются в «строке подключения ODBC». Вся безопасность обеспечивается серверами SQL, причем подключаться будут базы с разных серверов и разными драйверами (MS SQL и MySQL) но с одной и той же парой логинпароль. Это позволило бы сэкономить кучу времени. Можно было бы просто конструкторами создать запросы и формы, тем более количество вводимых данных небольшое. Вдобавок избежать проблем с драйверами ODBC и созданием пользовательских DSN’ов на клиентах.

Так пока и не нашел простой реализации без ADO/DAO и динамической генерации строки подключения.

Access и ODBC (часть 1)

Для начала

ODBC (Open DataBase Connectivity) — это открытый интерфейс доступа к базам данных, разработанный фирмой Microsoft. Он представляет собой API довольно низкого уровня и предназначен, в основном, для прямого использования в программах, написанных на C, C++ или, в крайнем случае, на VB. Несмотря на своё происхождение, этот интерфейс является кроссплатформным и с успехом работает и в Windows, и в UNIX/Linux, и в MacOS.

Нет ничего невозможного и в том, чтобы воспользоваться функциями этого замечательного интерфейса из VBA Access. Надо только ясно представлять себе, что большая часть работы уже и так проделана разработчиками MS Access. Для того, чтобы понять, что же осталось на нашу долю, рассмотрим более подробно сам механизм ODBC.

Как это работает

За относительно долгую историю ODBC API про него написано уже достаточно статей и даже книг, в которых подробнейшим образом описано из чего состоит, как работает этот интерфейс и как им пользоваться. Нам будет вполне достаточно лишь общего представления о его структуре.

Читайте так же:

Поле мемо в access 2020

Итак, для нас ODBC — это, прежде всего, Менеджер драйверов ODBC (для платформы Win32 это odbc32.dll). Драйверы непосредственно взаимодействуют с источниками данных. Что это за драйверы и как осуществляется такое взаимодействие для нас не важно. Просто, когда мы хотим получить доступ, например, к MS SQL Server 7.0, то нужно установить драйвер MS SQL Server 7.0, когда к серверу MySQL — драйвер MySQL.

Работа с Менеджером драйверов ODBC (далее — просто Менеджер) заключается в вызове необходимых функций с определёнными параметрами и в определенной последовательности. В функции Менеджера входит:

установка и завершение связи с источником данных (сервером БД);
подготовка и выполнение SQL-операторов;
получение результатов и навигация по полученным наборам записей, если имеется такая возможность;
управление транзакциями;
идентификация ошибок;
получение различной вспомогательной информации и прочие функции.

Для выполнения этих функций Менеджер вначале должен подготовить некоторые системные ресурсы:

Идентификатор окружения HENV. Он указывает на область памяти для общей информации (сведения обо всех соединениях с базами данных, информация о том, какое соединение является текущим и т.п.).
Идентификатор соединения HDBC. Этот идентификатор указывает на область памяти для информации о конкретном соединении. Идентификатор соединения ассоциируется с единственным идентификатором окружения, в то время как этот идентификатор окружения может иметь несколько связанных с ним идентификаторов соединения.
Идентификатор оператора HSTMT. Он указывает на область памяти для информации об SQL-операторе. Идентификатор оператора связан с единственным идентификатором соединения. Идентификатор соединения может иметь более одного связанного с ним идентификатора оператора.

В конце Менеджер должен освободить эти ресурсы и вернуть их системе.

С точки зрения программы на VBA, все эти идентификаторы — просто переменные типа Long, в которых хранятся адреса соответствующих областей памяти. При выделении ресурсов идентификатору, его переменная передаётся в специальную функцию по ссылке. При последующем использовании — по значению.

Немного практики

Перво-наперво, создадим отдельный модуль, в котором будем держать все объявления констант, функций, типов и переменных, так или иначе связанных с ODBC API. Бесхитростно назовём его «ODBC_API» и, для начала, включим следующие строки:

Здесь SQLDrivers и SQLDataSources уже не просто выполняют сервисные функции, а позволяют получить конкретные данные об установленных в операционной системе драйверах ODBC и именах источников данных (DSN — DataSource Name). Выглядят объявления этих функций довольно громоздко, но далее я подробно их опишу.

Так как эти функции получают информацию непосредственно от Менеджера, потребность в выделении ресурсов на соединение и операторы отсутствует. Достаточно лишь инициализировать идентификатор окружения HENV. Сделать это лучше всего, создав специальный модуль класса. Почему? Потому, что выделение и освобождение ресурсов можно осуществить, соответственно, в конструкторе (Class_Initialize) и деструкторе (Class_Terminate) класса и, тем самым, исключить ситуацию, когда при сбросе программы функция освобождения ресурсов SQLFreeEnv не будет вызвана. Итак, назовём его ODBC_HENV:

Теперь, при создании экземпляра класса, будет происходить выделение ресурсов окружения, а при уничтожении — их освобождение. Это очень похоже на работу с сеансом (Workspace) MS Assess. На этом подготовку можно считать законченной. Перейдём к следующему этапу — получению какой-нибудь полезной информации с помощью ODBC API.

Например, попробуем получить списки всех зарегистрированных драйверов и источников данных. Именно зарегистрированных, потому что эта информация просто читается из реестра Windows или из определённых конфигурационных файлов. Если физически удалить файл драйвера, то он всё равно останется в списке, но при попытке обращения к нему Менеджер будет выдавать ошибку. Аналогично, если новый драйвер просто скопировать в системную папку Windows, он не появится в списке установленных драйверов и работать с ним будет невозможно. Именно поэтому, драйверы ODBC обычно комплектуются специальной программой установки.

Чтобы получить интересующие нас списки, есть пара объявленных ранее функций: SQLDrivers и SQLDataSources. Они настолько похожи, что рассматривать я буду только первую из них, хотя использоваться будут обе. Первым параметром в ней идёт идентификатор окружения. Будем считать, что он у нас уже есть:

Дальше идёт параметр Direction. Он определяет порядок просмотра результирующего множества. И надо сказать, что и другие функции ODBC, работающие с наборами записей, устроены аналогично. Когда мы хотим получить первый элемент набора, надо передать в функцию значение SQL_FETCH_FIRST, следующее — SQL_FETCH_NEXT, предыдущее — SQL_FETCH_PRIOR и т.д.

Читайте так же:

Dcount в access примеры

Потом следуют два блока из трёх параметров каждый, которые служат для получения собственно информации о драйверах. Первый блок — название драйвера, второй — список атрибутов. Не пугайтесь, для этого списка не понадобится последовательный вызов ещё какой-нибудь функции. Имена атрибутов и их значения перечислены через стандартный для языка С (а именно на этот язык и рассчитан интерфейс ODBC в первую очередь) код завершения строки — 0 (ноль). В первом параметре каждого из двух блоков передаётся строка определённой длины, специально выделенная заранее:

Второй параметр — длина этой строки. Он не позволит функции сформировать слишком длинную строку, испортив при этом соседние ячейки памяти. В нашем случае — это просто MAX_DATA_BUFFER. Третьим идёт указатель на целое число, в которое функция запишет, сколько она на самом деле использовала символов в отведённой строке:

Вот и вся премудрость. Дальше — дело техники: в цикле заполняем пару таблиц данными о драйверах (название и атрибуты) и источниках данных (имя и название драйвера), а потом выводим их содержимое с помощью простенькой формы. Полностью пример для Access’97 можно взять здесь.

Access и ODBC (часть 2)

Уровни функциональных возможностей ODBC API

В ODBC существует несколько уровней функциональных возможностей, которые обеспечивают различные уровни взаимодействия с прикладными программами. Например, функция SQLConnect, относящаяся к базовому уровню, загружает драйвер и устанавливает соединение с источником данных на основе лишь идентификатора соединения и строки подключения, в которой, как правило, указываются имя источника данных, имя пользователя и пароль.

Первый уровень расширения функциональных возможностей ODBC включает в себя функцию SQLDriverConnect (она будет рассмотрена далее), которая позволяет запрашивать у пользователя более подробную информацию о подготавливаемом соединении, а также задавать степень обязательности этого запроса.

Второй уровень ODBC API включает в себя функцию SQLBrowseConnect, поддерживающую пошаговый метод ввода данных, которые необходимы для установления соединения с источником данных.

В реальности, соответствие ODBC драйвера некоторому уровню означает то, что он поддерживает все функции данного уровня. При этом в нём, как правило, реализованы ещё и некоторые из функций более высокого уровня. Существуют специальные функции, которые позволяют точно определить возможности драйвера.

Уровни соответствия SQL

Уровень соответствия SQL — это показатель того, какие возможности языка SQL и типы данных поддерживает драйвер. Грамматика ODBC SQL может быть базовой (она соответствует стандартным требованиям), минимальной (более низкий уроверь по сравнению с базовым) и расширенной (обеспечивает некоторые общепринятые расширения SQL).

Как и в случае уровней ODBC API, существуют функции, позволяющие определить, какие операторы и типы данных поддерживает драйвер.

Более сложная задача

В предыдущей части я описал лишь основы использования интерфейса доступа к данным ODBC. Создание полнофункциональных приложений, основанных непосредственно на этом API, по сравнению с разработкой на MS Access, представляет собой исключительно трудную задачу.

Чтобы не быть голословным, я приведу здесь небольшой пример, который иллюстрирует, насколько много нужно написать кода, для того, чтобы всего лишь получить список пользовательских таблиц с выбранного сервера БД.

Перво-наперво, откажемся от использования классов для «обёртывания» функций, отвечающих за выделение и возврат ресурсов. Это не прибавит нашей программе надёжности, но зато значительно сократит её объём и улучшит читаемость кода. А функций таких будет много — полный комплект для всех трёх уровней структуры API (окружение-соединение-оператор).

Далее, дополним модуль ODBC_API новыми объявлениями констант и функций:

Для непосредственной работы создадим форму, в которой разместим список драйверов ODBC, поля для ввода параметров подключения к серверу (имя сервера, имя базы данных на нем, логин и пароль пользователя), а также список таблиц, который и будем пытаться заполнить. Ещё предусмотрим пару кнопок для придания большей наглядности нашим опытам (хотя, можно обойтись и обработкой событий списков).

Список драйверов заполним по аналогии с предыдущим примером, только не будем создавать и наполнять таблицу. Вместо этого, в качестве типа источника строк выберем список значений, а при загрузке формы запишем в переменную наименования всех найденных драйверов и присвоим её свойству «Источник строк» списка.

Читайте так же:

Как создать гиперссылку в powerpoint

Следующий важный шаг — установить соединение с сервером. Информация, которая должна понадобиться — это, кроме имени драйвера, имена сервера и БД, а также логин и пароль пользователя, от лица которого будет осуществляться подключение. Вся вместе она образует так называемую строку подключения (Connection String), где перечисляются соответствующие ключи и их значения:

Нетрудно заметить, что в качестве значений мы указываем как раз содержимое элементов управления нашей тестовой формы. Теперь передадим эту строку вместе с уже имеющимся идентификатором окружения в предварительно заготовленную функцию, которая выполнит всю работу и, в случае успеха, вернёт ненулевой идентификатор соединения. Или нулевой — в случае ошибки. Вот она:

Основа нашей функции — функция ODBC API SQLDriverConnect. Первым параметром в ней идёт уже знакомый нам идентификатор соединения, который надо предварительно получить с помощью функции SQLAllocConnect. Второй параметр — идентификатор окна, которое будет являться родительским для окна диалога ввода параметров соединения. Этот диалог обеспечивается используемым драйвером ODBC, если мы того захотим и укажем в последнем параметре вызова функции соответствующий режим. В нашем случае диалог не требуется и поэтому мы передаём нулевой идентификатор окна (в противном случае можно передать, например, hWndAccessApp) и SQL_DRIVER_NOPROMPT соответственно.

Третьим и четвёртым парамертами идут строка подключения и размер текстового буфера, отведенного этой строке. Последующие три параметра функции предназначены для возврата строки подключения, сформированной самой функцией и, в нашем случае, не используются.

После того, как соединение установлено, подготовим идентификатор оператора с помощью функции SQLAllocStmt и вызовем функцию SQLTables. Эта функция возвращает набор сведений о таблицах (TABLE), представлениях (VIEW) и других аналогичных объектах базы данных. Использовать её нужно также, как и все функции, работающие с результирующим множеством, каким является, например, результат выполнения запроса на выборку.

В двух словах, порядок действий такой: сначала нужно определить количество столбцов в результирующем множестве (SQLNumResultCols), затем их имена (SQLColumns) и типы данных (SQLDescribeCol). Для нашего примера всё это не нужно, так как точно известно, что имена таблиц содержатся в третьем столбце, имеют символьный тип данных, а название столбца не имеет значения. Теперь можно выделить буферы для данных каждого из столбцов с помощью функции SQLBindCol. Мы этого делать не будем, а воспользуемся другим способом извлечения данных (SQLGetData). Далее необходимо, устанавливая указатель на нужную запись с помощью функции SQLFetch или SQLExtendedFetch (последняя поддерживается не всеми драйверами), считывать данные столбца в подготовленную для них переменную.

Как видите, всё это очень сложно и громоздко. Поэтому, многими фирмами разработаны различные программные компоненты более высокого уровня, существенно облегчающие использование таких интерфейсов, как ODBC. В MS Access для этого можно использовать механизмы присоединённых таблиц и запросов к серверу. В программах на VBA удобно использовать объекты доступа к данным DAO. Все перечисленные механизмы имеют ряд особенностей, которые необходимо знать, учитывать и использовать при работе с данными через интерфейс ODBC. Однако, это уже тема для отдельного разговора.

Управление источниками данных ODBC

Open Database Connectivity (ODBC) — это протокол, используемый для подключения базы данных Microsoft Access к внешнему источнику данных, например Microsoft SQL Server. В этой статье содержатся общие сведения об источниках данных ODBC, способах их создания и подключения к ним с помощью Microsoft Access. Действия, которые требуется выполнить, зависят от используемых баз данных и драйверов ODBC.

В этой статье

Сведения об источниках данных ODBC

Источник данных — это источник, который содержит данные и сведения о подключении, необходимые для доступа к этим данным. Источником данных может быть сервер SQL Server, реляционная СУБД Oracle, электронная таблица или текстовый файл. Сведения о подключении могут включать расположение сервера, имя базы данных, идентификатор входа, пароль и различные параметры драйвера ODBC, описывающие способ подключения к источнику данных. Эти сведения можно получить у администратора базы данных, к которой нужно подключиться.

В архитектуре ODBC приложения (такие как Access) подключаются к диспетчеру драйверов ODBC, который, в свою очередь, использует конкретный драйвер ODBC (например, Microsoft SQL ODBC) для подключения к источнику данных. В Access источники данных ODBC используются для подключения к внешним источникам данных, у которых нет встроенных драйверов.

Читайте так же:

Access recordset примеры

Чтобы подключиться к такому источнику данных, выполните указанные ниже действия.

Установите соответствующий драйвер ODBC на компьютере с источником данных.

Определите имя источника данных (DSN) с помощью программы Администратор источников данных ODBC, чтобы сохранить сведения о подключении в реестре Microsoft Windows или DSN-файле, либо с помощью строки подключения в коде Visual Basic, чтобы передать сведения о подключении непосредственно диспетчеру драйверов ODBC.

Машинные источники данных

Машинные источники данных хранят сведения о подключении в реестре Windows на определенном компьютере. Такие источники данных можно использовать только на компьютере, на котором они определены. Есть два типа машинных источников данных: пользовательские и системные. Пользовательские источники данных доступны и отображаются только для текущего пользователя. Системные источники данных могут использовать все пользователи компьютера. Они отображаются для всех этих пользователей и системных служб. Машинные источники данных особенно полезны, когда требуется обеспечить дополнительную защиту, поскольку машинный источник данных могут просматривать только вошедшие в систему пользователи. Кроме того, такой источник нельзя удаленно скопировать на другой компьютер.

Файловые источники данных

Файловые источники данных (также называемые DSN-файлами) хранят сведения о подключении в текстовых файлах, а не в реестре Windows, и, как правило, более гибки в использовании, чем машинные источники данных. Например, файловый источник данных можно скопировать на любой компьютер с подходящим драйвером ODBC, чтобы обеспечить в приложении точность и согласованность сведений о подключении ко всем используемым компьютерам. Кроме того, можно поместить файловый источник данных на отдельный сервер, сделать его общим для нескольких компьютеров в сети и легко управлять централизованными сведениями о подключении.

Некоторые файловые источники данных нельзя сделать общими. Такие источники располагаются на отдельном компьютере и указывают на машинный источник данных. Их можно применять для доступа к существующим машинным источникам данных из файловых источников данных.

Строки подключения

В модуле можно определить форматированную строку со сведениями о подключении. Строка подключения передает сведения о подключении непосредственно диспетчеру драйверов ODBC. Это помогает упростить приложение, устраняя необходимость создания DSN администратором или пользователем перед использованием базы данных.

Дополнительные сведения об интерфейсе ODBC см. в разделе MSDN Справочник программиста по ODBC.

Добавление источника данных ODBC

Прежде чем продолжить, установите подходящий драйвер ODBC для источника данных, к которому нужно подключиться.

Примечание: Для добавления или настройки источника данных ODBC необходимо входить в группу администраторов локального компьютера.

Нажмите кнопку Пуск и выберите пункт Панель управления.

На панели управления дважды щелкните элемент Администрирование.

В диалоговом окне «Администрирование» дважды щелкните элемент Источники данных (ODBC).

Откроется диалоговое окно Администратор источников данных ODBC.

Откройте вкладку Пользовательский DSN, Системный DSN или Файловый DSN в зависимости от типа источника данных, который нужно добавить. Дополнительные сведения см. в разделе Сведения об источниках данных ODBC.

Нажмите кнопку Добавить.

Выберите драйвер, который нужно использовать, и нажмите кнопку Готово или Далее.

Если необходимого драйвера нет в списке, обратитесь к администратору базы данных, к которой нужно подключиться, и узнайте, как получить этот драйвер.

Следуйте указаниям и введите требуемые сведения о подключении в последующих диалоговых окнах.

Для получения дополнительных сведений об отдельных параметрах нажмите кнопку Справка в диалоговом окне ODBC.

Подключение odbc access

Всем привет.
Очень нужна помощь. У меня есть программа написанная мною на Дэлфи которая подключена через ODBC к базе Access.

Вопрос
Каким образом можно эту же программу подключить к этой же базе без использования ODBC.
Например взял я програмку и базу положил в одну папочку и кинул на разные компютеры без настройки ODBC. А клиент сел за машину открыл папочку запустил программу и работает.. Без всяких заморочек с настройками.

← →
Slider007 © ( 2009-09-23 09:02 ) [1]

← →
Ksandr ( 2009-09-23 09:07 ) [2]

Прошу прощения за наглость а поподробнее.

Потому что я и так и спользую ADOConnection и ADOTable—>DbGrid.

← →
Медвежонок Пятачок © ( 2009-09-23 09:11 ) [3]

Читайте так же:

Не устанавливается powerpoint 2020

Без всяких заморочек с настройками.

← →
Ksandr ( 2009-09-23 09:17 ) [4]

Представь себе Я отправляю по почте программу c базой в другой город рядовому бухгалтеру который кроме 1с нечего в жизни не видел и каким образом он настроит ODBC.

накой хрен ему надо?
джет драйвер + строка подключения.

← →
Ksandr ( 2009-09-23 09:39 ) [6]

Ну желания клиента Не обсуждаются.

джет драйвер + строка подключения. Так то оно так.

Только вот если папочку перенести например на вторую половинку жестяка программка уже не работает.

> отправляю по почте программу c базой в другой город рядовому
> бухгалтеру который кроме 1с нечего в жизни не видел

Так первая же заморочка, с которой он столкнется, — куда положить все это полученное о тебя добро)

> если папочку перенести например на вторую половинку жестяка
> программка уже не работает

Значит кривая программа, если она не реализует защиту от бухгалтера)

> желания клиента Не обсуждаются

Клиент настолько продвинутый, что понимает разницу между «через ОДБС» и «через ДЖЕТ» ?)

← →
Ksandr ( 2009-09-23 09:47 ) [10]

> Так первая же заморочка, с которой он столкнется, — куда
> положить все это полученное о тебя добро)

Какое добро то. папка, в ней 2 файла один называется Base.mdb Второй пусть будет Project1.exe
Положил он например на рабстол эту папку открыл её и работает с программой потом у него произошел клин, через неделю ему захотелось её перенести на C:
Открывает опа а она уже не работает. Вот меня и гложет вопрос с помощью чего подключить Access и Delphi что бы они всегда находили друг друга и работали.

← →
Ksandr ( 2009-09-23 09:49 ) [12]

> Клиент настолько продвинутый, что понимает разницу между
> «через ОДБС» и «через ДЖЕТ» ?)

Да причем тут продвинутый он находится за 3 тыс км Кто ему настраивать то будет этот ODBC.

Да и вобще причем тут клиент. Какая разница какой он пользователь плохой или хороший сказано сделать значит сделать.
Ну вот и вопрос как.

Вот меня и гложет вопрос с помощью чего подключить Access и Delphi что бы они всегда находили друг друга и работали.

без разницы с помощью чего.
главное что бы программу писал программист.

Кто ему настраивать то будет этот ODBC.

На кой хрен его настраивать-то?

> через неделю ему захотелось её перенести на C:

Интересно, а почему у него через неделю не произошел клин перенести на флешку папку, куда инсталлирована клиентская часть 1С ?

> опа а она уже не работает

Значит у тебя ошибка в программе.

← →
Ksandr ( 2009-09-23 10:37 ) [17]

> джет драйвер + строка подключения.

Сначала неправильно указал Базу Щас переделал все работает Спасибки Медвежонок Пятачок. Ты настоящий Друг ;-)))))))))))))

Ну и с ODBC-подключением все точно так же решается

> Ksandr (23.09.2009 09:47:10) [10]

С JET это безпроблемно, ошибка у тебя.

← →
Ksandr ( 2009-09-23 13:25 ) [20]

> С JET это безпроблемно, ошибка у тебя.

Да да спасибо я уже разобрался.

С ODBC это безпроблемно, ошибка у тебя.

просто не надо использовать пред настроенные алиасы, ADO позволяет указывать драйвер с параметрами в строке подключения.

другое дело для access переход на jet идеологически более верен, т.к. убирается лишняя прослойка.

голоса

Рейтинг статьи