Использование Visual Studio 6.0 для доступа к SQL Server 7.0

Visual Studio — идеальное средство воплотить мощь SQL Server 7.0 в решениях.

Microsoft Corporation

Октябрь 1998

Обзор: В процессе обсуждения возможности использования Microsoft® Visual Studio® 6.0 для доступа к Microsoft SQL Server™ 7.0. (10 печатных страниц) появляются ответы на вопросы, которые обычно задают разработчики, среди которых:

·         Как наилучшим образом использовать Visual Studio 6.0 для доступа к SQL Server 7.0?

·         Что надо по-другому программировать или изменять в моем приложении?

·         Будут ли существующие приложения работать на новой платформе?

·         Что мы можем сделать, чтобы немедленно начать использовать преимущества новых средств?

Содержание

Что нового?

По сравнению с версией 6.5 эта версия SQL Server гораздо более сложная. В ней была переопределена основная структура хранения данных. Механизм запросов и управления СУБД также был существенно переработан. SQL Server 7.0 был спроектирован с учетом многих нововведений в распределенной архитектуре и логике данных, представленных и усовершенствованных Microsoft за последнее десятилетие. В нем были реализованы такие новые технологии, как Microsoft ActiveX® Data Objects (ADO) 2.0, OLE DB, Component Object Model (COM) и Distributed COM (DCOM).

Первые шесть аспектов, которые, вероятно, будут интересны разработчикам, это:

1)    Подключенные сервера (linked servers) — теперь стало возможным соединение с базами данных Oracle и др.

2)    Использование служб поддержки принятия решений SQL 7.0 (Decision Support Services — DSS) для аналитической обработки данных в интерактивном режиме (OLAP).

3)    Управление версиями хранимых процедур с помощью Microsoft Visual SourceSafe™.

4)    Отладка хранимых процедур в Visual Studio 6.0.

5)    Визуальное создание хранимых процедур в Visual Studio 6.0.

6)    Создание диаграмм баз данных.

Эти темы рассмотрены на специальном веб-сайте, посвященном Visual Studio по адресу: http://msdn.microsoft.com/vstudio/
и веб-сайте MSDN — http://msdn.microsoft.com/developer/default.htm.

K#Как использовать Visual Studio для доступа к SQL Server 7.0?

Мастера корректировки плохого проекта не существует. В очень многих случаях "относительно сложные" проекты при преобразовании их в масштабируемые приложения вызывают чувство разочарования. Перед тем как перейти к масштабированию до SQL Server, убедитесь, независимо от языка программирования, что у вас хороший, основательный и нормализованный проект. Средства, входящие в состав Visual Studio, могут сделать разработку приложений клиент/сервер или многоуровневой структуры более продуктивной за счет сокращения объема исходного кода программы.

Интерактивная разработка

Уникальное и не имеющее себе равных свойство Visual Studio — остановиться и взаимодействовать (stop and interact) с SQL Server, чтобы облегчить взаимодействие приложений с СУБД. В SQL Server предусмотрена возможность вовлечения приложений в диалог с процессором БД. Разработчики могут легко использовать «мгновенное» окно Visual Studio - immediate для ввода «вопросов» или команд в виде запросов и получения «ответов» от SQL Server. Они также могут использовать возможность SQL Server возвращать трассировочную и отладочную информацию с помощью опции отладки Enterprise Edition's T-SQL (Transact SQL). Это помогает разработчику увидеть, о чем «думает» СУБД, какой процесс используется для выполнения запроса и возникающие при этом ошибки.

Замечание   В некоторых случаях у вашего пользователя может возникнуть необходимость задать непредвиденный вопрос об информации, хранящейся в базе данных. В некоторых приложениях есть специальные диалоговые окна для ввода пользователем SQL-запроса. В таких случаях большая проблема заключается в недостатке контроля за этими запросами. Плохо структурированный запрос может вызвать падение производительности системы. Теперь, благодаря средствам DSS, входящим в SQL 7.0, вы можете создавать для пользователей заранее подготовленные эффективные запросы, которые не приведут к «торможению» системы.

Взаимодействие клиент/сервер

Большинство таких приложений обращаются к SQL Server, используя технологию клиент/сервер. При таком довольно простом подходе устанавливается связь с SQL Server по локальной сети (LAN) или с помощью локальной версии SQL Server передаются один или несколько запросов, обрабатываются результаты и происходит отсоединение. Эти приложения включают жестко запрограммированные T-SQL или параметрические запросы, либо, в большинстве случаев, активизируют T-SQL хранимые процедуры. Приложения могут взаимодействовать с SQL Server посредством любого API или интерфейса на уровне объектов. Они работают с обычными рядами данных и большими двоичными объектами (BLOB), а также данными типа TEXT и других форматов SQL.

Рисунок 1. ЛВС клиент/сервер

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

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

Клиентская система не должна быть настолько мощной, чтобы выполнять широкий спектр разнообразных задач, поскольку приложения для нее, как правило, не используют ресурсы интенсивно. У большинства хорошо написанных приложений небольшие запросы и они не создают большую нагрузку на сеть. Фактически приложения с архитектурой клиент/сервер могут работать нормально даже при связи посредством низкоскоростного модемного соединения (RAS),.

В архитектуре клиент/сервер операции манипулирования базами данных выполняются на стороне сервера. Эта логика обычно реализуется в виде хранимых процедур, триггеров и правил, кодированных в T-SQL. При использовании в сочетании с соответствующими мерами безопасности, этот централизованно управляемый код может увеличить защищенность и значительно улучшить производительность системы. Кроме того, поскольку приложение не содержит жестко кодированных запросов, оно неизбежно делает основную схему или логику доступа к данным более управляемой. Во многих случаях эти изменения не требуют повторного развертывания клиентских приложений.

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

Хранимые процедуры могут содержать простой запрос SELECT или очень изощренную логику. Эта логика возвращает данные из одной или нескольких таблиц или просто информацию о состоянии базы данных либо выполняет операции по изменению сложных данных. По существу такая технология переносит на SQL Server выполнение многих операций низкого уровня и бизнес-логику. Хранимые процедуры могут возвращать один или несколько результирующих наборов и часто требуют передачи параметров в обоих направлениях. Они составляют фундамент наиболее профессиональных реализаций архитектуры клиент/сервер. Именно поэтому в Visual Studio уделено так много внимания поддержке хранимых процедур. Visual Studio 6.0 обеспечивает отладку T-SQL, что позволяет разработчикам «внедриться» в хранимую процедуру непосредственно в процессе ее выполнения — прямо из среды разработки.

SQL Server 7.0 по-прежнему опирается на хранимые процедуры для обеспечения высокого уровня безопасности, быстродействия и приспосабливаемости интерфейсов к данным. Что касается произошедших изменений, то теперь эти процедуры стали реентерабельными, т.е. после того, как они были загружены в память, их могут одновременно использовать несколько клиентов. Это позволяет существенно экономить не только время, но и ресурсы памяти и процессора со стороны сервера, а также сокращает число дисковых операций ввода-вывода. Приложениям Visual Studio не приходится делать что-то специально, чтобы воспользоваться этими нововведениями, поскольку они просто вызывают хранимые процедуры для выполнения своих запросов.

Во многих приложениях (за исключением случаев, когда предусмотрено обратное) управление наборами результатов запросов возложено на т.н. курсоры. По сути, курсор представляет собой набор указателей на ряды данных, ограниченные SQL-запросом. От того, насколько эффективно интерфейсы Visual Studio и Data Access Object (DAO) манипулируют этими структурами, зависит, главным образом, производительность всего приложения. Поэтому как клиент, так и серверы должны управлять курсором эффективно. В SQL Server 7.0 были улучшены операции с курсором на стороне сервера, поэтому приложения и хранимые процедуры, построенные в соответствии с таким подходом, могут работать более эффективно, особенно в многопользовательской среде. Разработчику, использующему Visual Studio, не придется вносить каких бы то ни было изменений, чтобы использовать преимущества этих нововведений — все происходит само собой, незаметно для него.

Архитектура распределенных компонентов

Следующее новшество в процессе проектирования приложений переносит еще больше логики с клиентской части на промежуточное звено системы. Это очень привлекательно, поскольку делает клиентские приложения проще и сокращает потребности в повторном развертывании после изменений бизнес-логики или интерфейса доступа к данным. При таком подходе в клиентский реестр заносят соответствующие изменения, которые перенаправляют доступ к компонентам уровня объектов на удаленный сервер с использованием модели DCOM. Такая архитектура позволяет разработчикам ссылаться на бизнес-объекты, а не на наборы результатов низкого уровня, а также использовать ссылки на логические узлы нескольким клиентам одновременно. Этот подход порождает ряд проблем, среди которых реентерабельность (повторная входимость) программы, управлением состоянием сессии пользовательского доступа, управление транзакциями, совместное использование соединений и безопасность системы. Раньше в системах, основанных на DCOM, решение этих вопросов возлагалось на разработчиков систем, а для реализации логики создавались C-компоненты.

Рисунок 2. Архитектура распределенных компонентов

Visual Studio 6.0 и Microsoft Transaction Server (MTS) изменили ситуацию. Теперь разработчики могут делать свои собственные "скроенные по фигуре" полностью скомпилированные компоненты. После создания компонентов с помощью простых операций буксировки (drag-and-drop) MTS может управлять тем, как, когда и где они выполняются. Это нововведение открыло абсолютно новую парадигму перед разработчиками, которым необходимо стремиться вынести как можно больше кода, связанного со спецификой данных за рамки клиентских приложений. Теперь разработчики могут реализовывать объектные интерфейсы данных, которые скрывают от клиента низкоуровневый доступ к данным, бизнес-правила, транзакции и физические операции.

Замечание   Большая часть магической (и тяжелой) работы здесь выполняется MTS. Он держит под контролем множество подробностей, включая (но не ограничиваясь) управление ресурсами, регистрацию компонентов, разделение кода, транзакции, опрос соединений и многое, многое другое. За более подробной информацией обращайтесь на www.microsoft.com/ntserver/nts/appservice/.

Архитектура DCOM также может улучшить существующие реализации систем клиент/сервер, поскольку удаленно исполняемые компоненты могут (и должны) по-прежнему иметь доступ к хранимым процедурам для своих операций обращения к данным на низком уровне. Однако эта архитектура меняет то, каким образом управляются транзакции и как клиентское приложение подходит к решению ряда основных проблем. Visual Studio был спроектирован так, чтобы сделать этот переход как можно проще, предоставляя все необходимые ссылки на объекты с помощью подсказок Microsoft IntelliSense®. Это упрощает доступ с использованием COM-компонентов, а также добавляет гибкости при их создании. В Microsoft Transaction Server прилагается множество примеров на Microsoft Visual Basic®, изучение которых сделает процесс более безболезненным.

Некоторые из основных различий, о которых должны знать разработчики, включают:

·         Управление транзакциями со стороны клиента больше не нужно. Существуют специальные компоненты MTS для управлениями транзакциями. Это означает значительное сокращение кода в клиентском приложении, а также улучшенный контроль за транзакциями.

·         Управление соединением также выполняется автоматически; это означает, что разработчикам не следует менять состояние соединения, которое «навязывается» всем компонентам, совместно его использующим.

·         Компоненты с доступом DCOM могут управлять состоянием, но это не рекомендуется, поскольку приводит к проблемам с масштабируемостью Компонент не может быть повторно использован до того, как MTS не будет уведомлен, что компонент обновил свое состояние. Клиентские приложения должны зависеть от метода доступа (используя параметры), а не от удаленных операций над свойствами (remote property operations).

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

Веб-архитектура

Самое последнее нововведение в архитектуре доступа к данным – это использование универсального взаимодействия, обеспечиваемого Интернетом (или вашим корпоративным интранетом). Эта технология зависит от браузера клиентской части. Нет, это не обязательно должен быть обозреватель Microsoft Internet Explorer, поскольку многим из этих проектов нужна лишь простейшая поддержка HTML. Да, многие из наиболее эффективных проектов используют динамические HTML-расширения Internet Explorer 4.0, Remote Data Services (RDS) и другие средства, но пользователи зачастую часто предпочитают простоту быстродействию.

Рис. 3. Веб-архитектура

Visual Studio 6.0 переводит создание приложений на основе Веб на качественно новый уровень. Разработчики могут создавать приложения, которые работают в среде Microsoft Internet Information Server (IIS) и выдают результаты в формате HTML 3.2. Это означает, что все разработчики могут использовать свои навыки и знание языков программирования для построения COM-компонентов, которые будут работать везде и с любым браузером. Как Visual Studio 6.0 обращается к SQL Server? Точно так же, как вы бы обращались к нему из любой программы. Вы можете использовать выделенные соединения или, что лучше, MTS и объединенные (pooled) соединения. Вы также можете использовать знакомый ADO-код для формирования результирующих наборов, которые можно связать с элементами управления или текстовыми полями — точно так же, как в приложениях на платформе Microsoft Windows®.

K# ActiveX-объекты доступа к данным– ADO

ADO – это стратегический высокоуровневый интерфейс Microsoft для всех видов данных. Он обеспечивает универсальный высокоэффективный доступ к данным, независимо от того, создаете ли вы пользовательский интерфейс базы данных  или промежуточный (middle-tier) бизнес-объект для использования в приложениях, инструментальных средствах, языках программирования или даже браузере Интернет. ADO – это объектный интерфейс OLE. Он является единственным информационным интерфейсом, который вам необходимо знать для создания приложений с простой структурой, либо решений с многозвенной архитектурой клиент/сервер и управляемых данными Веб-приложений.

K#Использование ADO для доступа к данным

ActiveX Data Objects (ADO) – это новейший объектно-уровневый интерфейс Microsoft для доступа к данным. Visual Studio может использовать ADO как любой другой интерфейс COM — включая новые Remote Data Services. Эта парадигма позволяет разработчикам компонентов передавать объекты наборов записей ADO Recordset обратно клиенту, где дополнительный ADO-код делает их доступными клиентскому приложению. Поскольку Internet Explorer 4.0 включает поддержку RDS, такой подход особенно полезен при создании приложений для поиска данных на основе браузера. Та же технология может быть использована и в распределенной архитектуре. Поскольку код RDS включает средства управления источником данных, вы можете также привязывать эти разрозненные наборы результатов к связанным с данными элементами интерфейса.

Функциональность ADO 2.0 была расширена за счет добавления возможностей, поддерживаемых конкурирующим стандартом RDO 2.0. Теперь ADO поддерживает развитую модель событий, а также некоторые абсолютно новые стратегии доступа к данным. Это включает возможность создавать автономные объекты наборов записей и оформлять их в виде локальных файлов в клиентской системе. Они могут быть востребованы и обновлены на протяжении долгого времени после разрыва соединения. Фактически мы можете создавать объекты наборов записей вообще не беспокоясь о соединении.

Сейчас ADO встроен в Visual Studio — везде, где есть обращение к данным. Это означает, что дизайнеры, мастера и отладчики знают о соединениях и командах ADO. ADO также встроен в новые программы-дизайнеры, такие как Data Environment Designer и Data Form Designer, а также в окно Data View. Благодаря этому добираться до данных (где бы они ни хранились, а не только к реляционным данным) из Visual Studio стало намного проще.

При работе с SQL Server можно использовать ADO для создания приложений, связь между которыми устанавливается посредством традиционной технологии клиент/сервер, или из компонентов промежуточного звена либо Веб-компонентов. ADO идеально подходит для архитектуры удаленных компонентов, поскольку поддерживает управление даже более сложными разрозненными наборами результатов. С помощью ADO вы можете встроить объект набора записей в компонент и передать его обратно клиентскому приложению (или веб-странице), где он будет обрабатываться кодом со стороны клиента. За более подробной информацией об ADO и RDS обращайтесь на http://www.microsoft.com/data/.

K#Будут ли уже существующие приложения работать на новой платформе?

В большинстве случаев ваши приложения будут работать с SQL Server 7.0. Рассмотрим несколько аспектов этого вопроса. Во-первых, низкоуровневый интерфейс (интерфейсы): SQL Server 7.0 по-прежнему использует "для связи с внешним миром" собственный интерфейс Tabular Data Stream (TDS). Все существующие программные интерфейсы, включая DB-Library, Open Database Connectivity (ODBC) и OLE DB используют TDS. Вопрос: Будут ли существующие приложения на основе VBSQL или DB-Library работать с SQL Server 7.0? Да, будут, но все нововведения никак не отражаются в этом устаревшем интерфейсе. Ничто не будет принуждать вас конвертировать свои приложения VBSQL. Вы сами наверняка захотите это сделать, когда увидите, насколько возможности OLE DB или ADO, отличаются от возможностей DB-Library.

K#Оптимизация производительности

Как и версия 6.5 (и предшествующие ей), SQL Server 7.0 по-прежнему поддерживает оба стандарта SQL – American National Standards Institute (ANSI) SQL и T-SQL, поэтому ваши существующие запросы будут работать. Однако, обработка запроса в SQL Server 7.0 изменилась. В более ранних версиях при наступлении времени выполнения запроса вам на выбор предлагалось два варианта его обработки. Вы могли передать непредвиденное предложение T-SQL, которое компилировалось, затем для него создавался план запроса, и он выполнялся. Вы могли также передать хранимую процедуру, которая использовала хранимый план запроса. В некоторых случаях вы выполняли запросы ODBC, которые создавали временные хранимые процедуры (в TempDB) для вашего соединения, что ускоряло процесс выполнения непредвиденного или параметрического запроса, еще не переданного постоянно хранимым процедурам. При таком подходе возникали определенные проблемы. Например, вопреки тому факту, что с SQL Server работали сотни и даже тысячи одинаковых клиентских приложений, выполняющих один и тот же набор запросов, он не мог "осилить" компилированные планы запросов, созданные для других (точно таких же) клиентов. Даже когда вы использовали хранимую процедуру, SQL Server приходилось загружать в память новую копию, если только там уже не было хранимой процедуры, которая не используется.

SQL Server 7.0 изменил многое из этого, благодаря полному перепроектированию компилятора запросов и механизма обработки, а также способа выполнения запросов в памяти. Прежде всего, SQL Server 7.0 позволяет другим клиентам запускать тот же запрос, чтобы использовать выполняющийся план запроса, откомпилированный и загруженный другим клиентом. Дело в том, что выполняющиеся запросы SQL Server 7.0 теперь реентерабельны. Это означает, что когда программа "A" выполняет запрос:

Select * From Authors Where Au_ID = 18

другой клиент, выполняющий идентичный запрос или похожий, но использующий другую константу для сравнения, может одновременно использовать тот же план запроса. Например, если программа "B" или другая часть программы "A" выполняет:

Select * From Authors Where Au_ID = 35

механизм обработки SQL Server 7.0 может повторно использовать выполняющийся или буферизованный план запроса — таким образом экономятся время и ресурсы, необходимые для перекомпиляции запроса с аналогичным планом.

Представляете, насколько это увеличивает производительность! Фактически чем больше клиентов, тем быстрее работает SQL Server. Это нововведение также означает, что SQL Server больше не нужно повторно загружать дополнительные копии хранимых процедур, когда хранимая процедура находится в работе, что позволяет клиенту совместно использовать уже запущенный вариант. Еще один нюанс заключается в том, что SQL Server 7.0 больше не создает хранимые процедуры TempDB для выполнения клиентом. Поскольку выполняющиеся запросы могут совместно использоваться всеми клиентами базы данных, новому механизму не надо хранить откомпилированные запросы и повторно загружать их при вызове параметрических запросов.

Самое невероятное в этом новшестве то, что вам, как разработчику ADO, абсолютно ничего не надо предпринимать. Если вы запускаете хранимые процедуры, они совместно используются более эффективно и выполняются как раньше. Если вам надо выполнить непредвиденные запросы или rdoQuery, или команды ADO, или запросы UserConnection, которые были откомпилированы в запросы TempDB, вы по-прежнему можете это сделать. Но теперь SQL Server 7.0 во всех случаях пытается использовать запрос в процедурном кэше вместо компилирования нового плана запроса и его выполнения.

SQL Server 7.0, несомненно, гораздо лучше использует оперативную память и свой процедурный кэш для реализации этих возможностей. Это нововведение означает повышение быстродействия и более высокий уровень масштабируемости, а также то, что вам практически не придется менять свои приложения. Вы можете использовать преимущества этих перемен:

·         Если вы передаете параметрический запрос, убедитесь (как вы делали это и раньше), что параметры помечены. Маркеры параметров помогают SQL Server 7.0 определить, не совпадает ли данный запрос с уже запущенным.

·         Если вы используете хранимые процедуры, продолжайте делать это — для операций с данными. Бизнес-логика должна быть сосредоточена в COM-объектах промежуточного звена. Ваши хранимые процедуры продолжают обеспечивать наилучшую производительность для операций с данными. При их использовании по-прежнему сохраняется необходимость предварительного компилирования для непредвиденных запросов, не присутствующих в процедурном кэше.

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

Замечание  Непредвиденные запросы — это предложения T-SQL, которые вы жестко кодируете в своем приложении или позволяете пользователю вводить непосредственно (чего, естественно,делать не рекомендуется) или косвенно с помощью опций, выбираемых программой или пользователем.

K#Что мы можем сделать сегодня, чтобы использовать преимущества новых средств?

Имейте в виду, что SQL Server 7.0 будет поддерживать все ваши существующие приложения в том виде, как они есть. Однако, в некоторых случаях нужно создать приложение, которому необходим доступ к данным как в подключенном, так и в автономном режиме, т.е. приложение должно работать и обрабатывать данные, даже если система не «видит» сеть. Универсальный сценарий поддерживает неподключенные базы данных с помощью Microsoft Jet (или Microsoft Access, что, по существу, одно и то же), а подключенные базы данных с помощью SQL Server. Это означало создание ODBC/RDO соединения с Jet, что является источником ряда проблем, поскольку драйверы ODBC для Jet никогда по-настоящему не были предназначены для решения задач такого типа. Теперь, когда SQL Server 7.0 может работать как в среде Microsoft Windows NT®, так и систем семейства Windows 9x, этот сценарий может быть пересмотрен. Возможно, наступило время переработки приложения и использования ADO для связи с обеими базами данных, Или можно предложить даже лучший сценарий: используйте репликацию SQL Server для связи вашего SQL Server для Windows 9x с центральным Windows NT SQL Server.

Имейте в виду, что SQL Server 7.0 улучшает хранение данных типа TEXT и IMAGE, но он также увеличивает размер страниц, чтобы разместить большие данные типа VarChar. C SQL Server 7.0 вы можете хранить немного меньше, чем 8000 байт в столбце VarChar (на 8000 меньше размера ключа). Это приводит к устранению или сокращению необходимости хранить сложные "страничные" типы данных.

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

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



K Microsoft Visual Studio 6.0, средства доступа к SQL Server 7.0; Microsoft SQL Server 7.0, доступ с помощью Visual Studio 6.0

# VS6_SQL7wp_usingvisualstudio

K ActiveX Data Objects (ADO), см ADO; ADO и SQL Server 7.0; Microsoft SQL Server 7.0 и ADO

# VS6_SQL7wp_ado

K ADO, accessing SQL Server 7.0 data with; Microsoft SQL Server 7.0, accessing data with ADO

# VS6_SQL7wp_usingado

K Microsoft SQL Server 7.0, compatibility; compatibility, SQL Server 7.0

# VS6_SQL7wp_currentapps

K Microsoft SQL Server 7.0, performance optimizations; optimizations, SQL Server 7.0 performance; performance optimizations, SQL Server 7.0

# VS6_SQL7wp_performance

K Microsoft SQL Server 7.0, taking advantage of new features; features, taking advantage of new SQL Server 7.0; taking advantage of new SQL Server 7.0 features

# VS6_SQL7wp_newfeatures