DROP THE BASE! ADO И БАЗЫ БАННЫХ

Pony (pony@xakep.ru)

Спецвыпуск Xakep, номер #028, стр. 028-020-1

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

ПОЧЕМУ ASP?

ASP использует для доступа к данным объекты ADO (ActiveX Data Object). ADO можно юзать для доступа к таблицам Excel, базам данных Access или текстовым файлам. Вообще, любой источник данных, который имеет ODBC драйвер и может быть использован в качестве ODBC базы данных в винде, также можно юзать для доступа через ADO. Общая логика работы с ADO такова: устанавливаем соединение с источником данных, считываем данные, выводим их в html-файл, закрываем соединение. И на каждом шаге работаем с объектами: создаем, наполняем, уничтожаем. И самое главное, при изменении источников данных не надо полностью переписывать код, вполне достаточно изменить строку, где описывается соединение.

КОННЕКТИМСЯ

ADO имеет простую объектную модель. И выше всех у нас тусует объект Connection. Создается он так:

Set soska = Server.CreateObject("ADODB.Connection").

Создать Connection еще не значит открыть это самое соединение. Сперва нужно намутить описалово соединения, для чего юзают свойство ConnectionString. Тут сидит вся инфа о Connection. Например, строка:

connection.ConnectionString = "Provider=SQLOLEDB;Source=local;UID=sa;PWD=;Database=pubs"

описывает соединение с SQL сервантом. Вместо connection, естественно, надо писать имя экземпляра объекта, который был создан (soska - в примере выше).

Описав соединение, его можно открывать:

connection.Open.

В общем случае синтаксис имеет вид:

connection.Open ConnectionString, UserID, Password, OpenOptions.

Все параметры можно явно не указывать и положить на них с высокой горы (типа - идите вы все по дефолту!). Но в таком виде код будет компактнее: не надо отдельной строкой указывать строку соединения. OpenOptions задает, в каком режиме будет открыто соединение. Этот режим описывают константы ConnectModeEnum:

adModeUnknown - по умолчанию;

adModeRead - соединение только для чтения;

adModeWrite - соединение только для записи;

adModeReadWrite - соединение для записи и чтения;

adModeShareDenyRead - запрещает открытие соединений на чтение, пока текущее соединение открыто;

adModeShareDenyWrite - запрещает открытие соединений на запись, пока текущее соединение открыто;

adModeShareExclusive - запрещает открытие соединений, пока текущее соединение открыто;

adModeShareDenyNone - запрещает открытие любых соединений, пока текущее соединение открыто.

То же самое можно зафигачить через свойство Mode объекта Connection еще до открытия соединения:

connection.Mode = adModeShareExclusive

ЭКОНОМЬ СЕРВАКИ!

Знаешь, как контачат ADO и IIS с соединениями? ADO видит соединение с базой как набор свойств, собранных в строку соединения. IIS создает пул соединений, куда складирует разные connection'ы, каждый из которых можно заюзать сколько угодно раз. Когда приложение запрашивает соединение, IIS проверяет, а не тусует ли уже в пуле свободный connection с такой же строкой соединения. Если нужное соединение удается найти, оно используется, если нет - создается новое. Таким образом, если в пуле удается нарыть открытое соединение с нужными свойствами, хитрый IIS просто возвращает линку на него и ни хрена не открывает. Так что пул ускоряет процесс установки соединений, ведь обычно юзают один источник данных и 2-3 типа доступа с разными паролями. Именно из-за организации пула запись объекта Connection в переменную Session замедляет работу сервака. Поэтому никогда так не делай.