Выпуск в свет CA-Visual Objects открывет дорогу ко многим самым современным технологиям. Первое и главное - это программирование в среде MS Windows. Однако, освоение программирования в среде Windows - это всего лишь входная плата в огромный новый мир. Помимо интерфейса GUI, среда Windows открывает перед разработчиками целый спектр других возможностей. Одна из них, поддерживаемая CA- Visual Objects, - это программирование в архитектуре "клиент-сервер". Это достигается через использование стандарта ODBC (Open DataBase Connectivity). Данный стандарт позволяет CA- Visual Objects иметь доступ к информации, записанной в любой внешней базе данных, если для нее разработан соответствующий ODBC-драйвер. Как это станет ясно в дальнейшем, такая возможность существенно расширяет горизонты для разработчиков-приверженцев языка Clipper.

Вместе с тем, по своей природе ODBC базируется на языке SQL (Structured Query Language). Для того, чтобы пользоваться средствами ODBC в CA-Visual Objects, необходимо с самого начала твердо понимать разницу между традиционной технологией доступа к данным XBASE и технологией доступа SQL. Полное описание последней выходит за рамки настоящего доклада, однако некоторые основные понятия и конструкции в нем будут рассмотрены. Если Вы решили использовать SQL в CA-Visual Objects, то Вам следует разобраться с соответствующими средствами в интегрированной среде разработки (IDE), а также в том, каким образом сохранять в репозитарии предопределенные SQL-классы как части Ваших приложений или библиотек.

В докладе рассматриваются темы, связанные с ODBC, классами серверов данных типа SQL, а также основные моменты разработки SQL-приложений. Обсуждаются вопросы правильного выбора ODBC-драйвера для используемой базы данных, администрирования подключением ODBC и дистрибуции ODBC-приложений. Мы рассмотрим несколько простых примеров, демонстрирующих мощь и другие преимущества, связанные с использованием ODBC. Примеры включают подключение к базам данных Microsoft Acces, Oracle 7, Excel, Text, .DBF, Paradox и др.

ODBC - сравнительно новый феномен. Впервые он был представлен в сентябре 1992 г. как часть архитектуры WOSA (Windows Open System Architecture). К концу 1992 г. несколько компаний, включая Watcom, Microrim и QuadBase уже представили на рынок драйверы, отвечающие этому стандарту. ODBC обеспечивает подключение ко многим форматам баз данных, в силу чего многие разработчики включают его в свой арсенал даже тогда, когда используют другие промежуточные средства доступа к наиболее популярным системам баз данных. В настоящее время насчитывается более двадцати фирм, поставляющих на рынок ODBC-драйверы, которые обеспечивают доступ к более чем пятидесяти форматам баз данных. Одна из фирм - InterSolv - разработала драйверы для 20 наиболее популярных баз данных. Эти драйверы поставляются вместе с пакетом CA-Visual Objects. Универсальность доступа - принципиальный фактор, который побуждает фирмы-разработчики СУБД, в том числе и CA, включать в свои продукты и планы разработок ODBC.

Один из наиболее частых аргументов против использования ODBC состоит в том, что претендуя на роль панацеи от всех бед, данный стандарт в то же время в качестве платы за это приводит к снижению производительности систем. Сторонники этого аргумента основывают свои суждения на собственном опыте, который они получили при разработке ранних версий ODBC-приложений, например, в системах Microsoft Access 1.x и MS Visual Basic. Кроме того, противники ODBC исходят из предпосылки, что этот стандарт требует от приложения дополнительных уровней интерфейса для доступа к наборам данных. Оценки эффективности ODBC, основанные только на опыте работы с такого рода продуктами, не отражают действительности. Для строгой оценки эффективности ODBC необходимо проводить четкие грани между эффективностями интерфейса (API), драйвера и самого клиентского приложения.

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

С учетом высказанных соображений, приложения, разрабатываемые в системе CA-Visual Objects с использованием ODBC, выигрывают даже при сравнении их с приложениями, использующими непосредственный доступ.

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

ODBC в некоторой абстрактной форме представляет источник данных, который включает в себя сервер, имя базы данных, схему, сетевую библиотеку и другую информацию, необходимую для подключения клиентского приложения к данным. В CA-Visual Objects эта абстракция предсталена в форме SQL-классов серверов данных. Эти классы определяются с использованием SQL-редактора, на котором мы остановимся чуть позже.

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

Большая часть концептуальных положений, поддерживаемая ODBC API, является общей для SQL-программирования (фетчи, транзакции и курсоры), однако некоторые API не включают в свой состав функции, отвечающие требованиям соответствия программного интерфейса клиентской и серверной частей. ODBC-приложения, использующие базы данных различных типов, для управления подключениями и обслуживания SQL-запросов требуют контекстно-чувствительной логики управления. ODBC использует управляющие блоки (handles) для управления хранилищем данных и контекст для среды, подключений и выполнения запросов, в то время как в CA-Visual Objects вся эта информация инкапсулируется в SQL-классах.

Функции ODBC могут фиксировать ноль, одну и более ошибок, поэтому хорошей практикой программирования является контроль на их наличие после вызова SQLError. Приложение может вызывать SQLError в любое время, но в большинстве случаев это делается, когда функции ODBC возвращают SQL_ERROR или SQL_SUCCESS_WITH_INFO. Для полного уяснения состояния базы данных, разработчик должен проверять SQLState и делать повторные вызовы SQLError до тех пор, пока ODBC не вернет SQL_NO_DATA_FOUND.

"Транспарентность к серверу" - одна из характерных черт, присущих ODBC и другим мультибазовым API. Суть ее состоит в том, что пользователь клиентской части наделяется возможностью использовать те специфические особенности SQL, которые присущи его конкретной реализации на серверной части. Использование этих особенностей может привести к повышению эффективности, функциональной гибкости и уровня оптимизации, что было бы невозможно при стандартном обращении к ODBC. Одним из примеров этого является конструкция вида START WITH ... CONNECT BY в SQL Oracle, которая отрабатывает иерархический запрос на таблице с тем, чтобы он имел "читабельный" вид в отчете:

LAST_NAME || ‘:’,

FROM EMPLOYEE

START WITH TITLE = “PRESIDENT”

CONNECT BY PRIOR EMP_NO = MANAGER

Этот запрос приводит к получению результата следующего вида:

Смит : Президент

Доу : Директор по маркетингу

Петерс : Менеджер по продажам

Пирс : Коммивояжер по восточному региону

Донато : Коммивояжер по западному региону

Омар : Менеджер по анализу рынка

Джонсон : Финансовый директор

Литтл : Главный бухгалтер

Пейтел : Бухгалтер

CA-Visual Objects также включает в себя такие возможности, обеспечивая тем самым разработчиков возможностью выполнения сохраненных процедур и целым ряд других преимуществ.

Для создания ODBC-приложения в системе CA-Visual Objects Вам следует инсталлировать ODBC (администратор и драйверы) и сконфигурировать источники данных. Эту работу выполняет инсталлятор системы, после работы которого в окне "Панель управления" Windows появляется иконка "ODBC Administrator". Прежде чем получить доступ к данным из Вашего приложения, необходимо использовать администратор ODBC для определения источников данных и другой требуемой информации (имя сервера, имя базы данных, сетевая библиотека, схема и т.п.).

CA-Visual Objects поставляется в комплекте с более чем двумя дюжинами драйверов ODBC фирмы Intersolv, снабженных собственной документацией. Изучение документации очень важно, поскольку в ней описываются многие "тонкие" моменты, такие как типы данных, уровни согласования со стандартом ODBC, информация по подключению, особенности локирования и т.д. Все эти моменты могут сыграть важную роль при работе более чем с одним источником данных. В частности, большинство баз данных SQL поддерживает более одного типа символьных и числовых данных. Например, Oracle различает такие типы как CHAR, LONG, VARCHAR и VARCHAR2, каждый из которых поддерживает строки различной длины. Перемещение недопустимого количества данных от одного поля к другому может привести к потери информации, а в некоторых случаях - и к более серьезным последствиям.

Поэтому перед началом разработки приложения обязательно изучите документацию по драйверам и тем СУБД, с которыми намереваетесь работать.

ODBC - это интерфейс уровня обращения ("call-level"). Он не относится ни к категории приложений, ни к категории сетевых драйверов, ни к категории драйверов баз данных. Для реалистичного оценивания влияния ODBC на эффективность приложения эти вещи надо четко понимать и не смешивать ODBC в одну кучу c API, сетевыми драйверами и драйверами баз данных. Практика разработок показывает отсутствие каких либо явных свидетельств существенного отрицательного влияния ODBC на эффективность работы программы.

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

Несмотря на то, что спецификации на стандарты ODBC 1.0 и 2.0 и появившийся в последнее время 3.0 представляют собой достаточно объемные и глубоко проработанные документы, сама концепция ODBC еще сравнительно молода. Поэтому вполне вероятны ситуации, когда тот или иной вопрос потребует уточнения и прояснения. В таких случаях следует обращаться в сеть CompuServe, в секцию ODBC раздела WINEXT, которая для разработчиков ODBC является официальной.

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

Итак, начнем с основ. Файлы состоят из записей, упорядоченных последовательно друг за другом. В общем случае при открытии файла имеется первая запись, некоторая серия следующих записей и фиктивная последняя запись, необходимая для возбуждения состояния "Конец файла" (EOF). Вы можете перемещаться по записям и выполнять над каждой записью необходимые действия. Понятие файла полностью взято из реальной жизни: файл - это электронный аналог обычной бумажной картотеки.

Модель SQL отличается от файловой модели тем, что данные рассматривает в виде некоторого набора данных, а не файла. Набор данных соответствует абстрактному математическому множеству, известному всем по школе. Множества никак не упорядочены и все их элементы имеют один тип. Когда Вы выполняете операцию на множестве, то она выполняется "одновременно" над всеми его элементами. Иными словами, если мы сформируем запрос типа "выдать подмножество всех четных чисел из множества положительных целых", то в результате получим сразу весь набор этих четных чисел. Мы не будем строить подмножество всех четных чисел поэлементно, т.е. просматривая последовательно все элементы исходного множества. Вместо этого мы должны определить правило отбора: "Если остаток от деления элемента множества на два равен нулю, то этот элемент - четное число". И этого достаточно для получения результата.

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

В докладе предполагается, что аудитория знает основы реляционной модели баз данных, может отличить базу данных от таблицы и колонку от строки. Однако, для полной ясности, дадим все-таки краткое определение таблицы.

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

Таблицы сами по себе обеспечивают довольно узкий и несовершенный взгляд на реальный мир. Для примера рассмотрим нормализованную базу данных, состоящую из таблиц с информацией о служащих и подразделениях. Просматривая таблицу подразделений, невозможно определить, сколько людей работает в данном конкретном подразделении. Аналогично, просматривая таблицу служащих, невозможно ответить на вопрос, как называется или где расположено подразделение, в котором работает данный служащий. Таблицы обеспечивают средство для хранения информации по конкретному типу объектов. Для построения полноценного приложения необходимы средства доступа по чтению и записи наборов данных, объединяющих информацию из многих таблиц. SQL - как раз тот язык, который предоставляет такие средства для большинства реляционных СУБД.

Также как и в традиционном Xbase-программировании, создание наборов данных и манипуляции с таблицами в SQL требуют весьма ограниченного количества команд. В CA-Clipper 5.x примерами таких команд являются USE, APPEND, DELETE и SET RELATION TO. В мире SQL ни одна из этих команд не имеет своего аналога. Это следствие того, что в SQL Вы имеете дело с наборами данных, которые Вы как разработчик определили. Принципиальными командами языка манипуляции данных SQL являются следующие: SELECT, INSERT, DELETE и UPDATE.

Команда SELECT в вышеприведенном перечне используется для извлечения набора данных. Назначение же всех других команд самоочевидно исходя из их названий. Пояснений требуют не назначения этих команд, а характер их практического использования. В рамках данного доклада мы остановимся подробно только на команде SELECT. Общая форма этой команды, а точнее говоря - оператора, следующая:

SELECT <выражение,...> <список колонок,...>

FROM <список таблиц,...>

WHERE <условие> <условия объединения>

GROUP BY <выражение,...>

HAVING <выражение,...>

ORDER BY <выражение,...>

В SQL, например, нет команды TOTAL. Для определения суммы по столбцу SALARY таблицы EMPLOYEE можно выполнить оператор следующего вида:

SELECT TOTAL( SALARY ) FROM EMPLOYEE

Это означает, что в SQL не требуется писать знакомые нам конструкции вида:

FUNCTION Total( Salary )

LOCAL nTotal

SELECT EMPLOYEE

GO TOP

DO WHILE ! EOF()

nTotal += Salary

ENDDO

RETURN nTotal

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

SELECT COUNT(*), DEPT_NAME

FROM EMPLOYEE

GROUP BY DEPT_NO

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

В качестве примера создадим набор данных, в котором будут присутствовать суммы всех заказов, сделанных клиентами в штате Нью Йорк. Оператор SQL в этом случае мог бы иметь такой вид:

PARTS.PART_NUM,

PARTS.ITEM_DESC,

TOTAL( LINEITEMS.QTY )

CUSTOMER,

ORDERS,

LINEITEMS,

PARTS

CUSTOMER.CUST_STATE = 'NY' AND

ORDERS.CUST_NUM = CUSTOMER.CUST_NUM AND

LINEITEMS.ORDER_NUM = ORDERS.ORDERNUM AND

PARTS.PARTNUM = LINEITEMS.PARTNUM

PARTS.PART_NUM

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

Существует также иной способ сокращения запроса, который основан на использовании алиасов. Тот же оператор SQL с использованием алиасов может иметь такой вид:

P.PART_NUM, P.ITEM_DESC, TOTAL( L.QTY )

CUSTOMER С, ORDERS O, LINEITEMS L, PARTS P

C.CUST_STATE = 'NY' AND O.CUST_NUM = C.CUST_NUM AND

L.ORDER_NUM = O.ORDERNUM AND P.PARTNUM = L.PARTNUM

P.PART_NUM

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

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

Ниже приводятся примеры операторов для выполнения специфических задач.

Для отбора всех служащих по алфавиту и их группировки по подразделениям:

SELECT LAST_NAME, FIRSTNAME

FROM EMPLOYEE

ORDER BY LAST_NAME

GROUP BY DEPT_NO

Для показа фамилий и имен сотрудников и наименований подразделений:

EMPLOYEE.LAST_NAME,

EMPLOYEE.FIRST_NAME,

DEPARTMENT.DEPT_NAME

EMPLOYEE, DEPARTMENT

EMPLOYEE.DEPT_NO = DEPARTMENT.DEPT_NO

EMPLOYEE.DEPT_NO

или

SELECT E.LAST_NAME, E.FIRST_NAME, D.DEPT_NAME

FROM EMPLOYEE E, DEPARTMENT D

WHERE E.DEPT_NO = D.DEPT_NO

ORDER BY E.DEPT_NO

Все необходимые средства для разработки приложений, использующих SQL, в CA-Visual Objects имеются. Интерфейс с пользователем обслуживается библиотекой Common View GUI, а поддержка SQL - библиотекой SQL. Common View автоматически обрабатывает события, связанные с выбором вариантов из меню или нажатием кнопок на панели управления, а также организует поток управления в немодальных диалогах и отображает в строке состояния подсказки относительно кнопок, полей данных и вариантов выбора меню.

Управляющие элементы в окнах Common View полностью осведомлены о данных: система осуществляет автоматическую загрузку данных из базы с их одновременным форматированием, а также их разгрузку в базу с предварительным контролем значений. Табличный редактор класса DataBrowser позволяет как разработчику, так и конечному пользователю управлять таблицей представления данных с использованием таких возможностей как перемещаемый разделитель таблицы, перемещаемые по принципу буксировки колонки, изменяемые размеры колонок.

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

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

Следующий шаг заключается в определении используемого класса SQL. Для того, чтобы Ваше приложение легко сопровождалось, создайте собственный модуль для Вашего первого SQL-класса (а в дальнейшем - собственный модуль для каждого следующего). Модулю следует дать наименование, раскрывающее особенности именно данного SQL-класса. Выберите этот модуль и запустите в работу редактор SQL-серверов. В открывшемся окне редактора присвойте опять же значимое имя создаваемому SQL-классу.

Выберите нужный драйвер, щелкнув мышкой на иконке с лупой, расположенной правее поля ввода Name. На экране появится диалоговое окно с перечнем всех источников данных SQL. которые определены администратором ODBC. Выберите и зарегистрируйте для себя необходимый драйвер и подключитесь к той таблице, с которой Вы намереваетесь работать. Если источник данных представляет собой СУБД типа Watcom SQL Server или Oracle, драйвер ODBC выполнит команду SQLFetch для извлечения имен всех таблиц в базе данных. В зависимости от конкретных условий, этот процесс может занять определенное время - от долей секунды до нескольких десятков секунд.

Вы можете выбрать таблицу или группу таблиц, на базе которых построить свой SQL-класс. После выбора очередной (или единственной) таблицы на стороне "Include" секции колонок редактор отображает имена всех колонок. Если Вы желаете исключить те или иные колонки из SQL-класса, то можете выполнить это с помощью кнопки ">".

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

Если Вы намерены объединить таблицы, CA-Visual Objects попросит Вас определить алиасы для колонок с дублирующимися именами.

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

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

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

Вы можете воспользоваться возможностью автоматического конфигурирования окна, щелкнув мышкой на иконке "Auto Layout", или выбрав опцию с тем же наименованием из меню "Edit". В любом случае редактор запросит у Вас имя связываемого с окном сервера данных. Кроме того, Вам необходимо сообщить редактору тип отображения: обычный или "мастер-детали". Последний тип надо выбирать тогда, когда необходимо обращаться к "подчиненному" серверу для отображения связей типа "один ко многим".

Спецификации полей - это объекты, которые управляют характером форматирования, отображения, редактирования и контроля данных. Определение класса спецификации поля для каждой колонки SQL-класса содержит в себе следующую информацию:

Свойство	Описание
Decimals	Количество знаком после десятичной запятой (точки) - только для числовых полей
Diagnostics	Гиперметки для каждого из правил контроля. Заметьте, что каждая гиперметка содержит в себе не только диагностическое сообщение, но также и ключевое слово для обеспечения контекстно-чувствительной подсказки в случае, если правило контроля не выполняется.
HyperLabel	Гиперметка с информацией о поле (имя поля, заголовок, описание и ключевое слово контекстно-чувствительной подсказки
Length	Длина поля
Min, Max	Допустимый диапазон значений
MinLength	Минимальное количество символов в поле. Например, поле STATE может быть определено с длиной в 2 символа и минимальной длиной в 2 символа, в то время как поле PASSWORD может иметь длину в 10 символов, а минимальную длину - 4 символа.

Свойство	Описание
Picture	Шаблон для форматирования поля. Этот шаблон задается в стандартном для Xbase-программирования виде, например @I или 999-99-9999.
Type	Тип поля (числовой, строковый, логический, дата или мемо)
Validation	Кодовый блок, который устанавливает правило контроля для данного поля ( проверки типа, диапазона и т.п.). Заметьте, что каждому подклассу спецификации поля может быть определен метод Validation(), который будет переопределять этот блок.

Установкой указанных свойств спецификации поля Вы управляете характером поведения соответствующей колонки при работе с таблицей.

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

В простейшем случае Вы можете активизировать окно данных непосредственно из меню главного окна-оболочки приложения EMPTY_SHELL_MENU. Это меню автоматически генерируется системой при создании приложения. Модифицируйте его с помощью редактора меню - например, добавьте в него дополнительную опцию в том месте, где посчитаете необходимым. В окне свойств этой опции, в графе "Event name" введите имя Вашего окна данных.

После успешной компиляции программы Вы можете запустить ее на выполнение и проверить совместную работу окна данных с SQL-сервером. Библиотеки классов Common View GUI и SQL позаботятся о всех низкоуровневых операциях с ODBC, SQL и экраном, которые должны быть выполнены при просмотре и редактировании Вашей таблицы или при добавлении в нее новых строк.

Всегда помните, что любое изменение данных в Вашем объекте класса SQL Select может привести к возникновению ошибки SQLError. Отслеживание и обработка подобных ошибок в процессе выполнения программы - очень важный аспект ее работы. Вместе с тем, большинство ошибок в приложениях, использующих SQL-классы, может быть исправлено только на этапе разработки. Следовательно, Вам следует основательно разобраться с механизмом управления базой данных, ее первичными ключами, сохраненными процедурами, триггерами, а также с неконтролируемыми ситуациями типа каскадного удаления, недостатком табличных привилегий и т.п. Все это может привести к непредсказуемому ходу событий при выполнении Вашей программы.

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

ODBC spells headache, Finkelstein, Richard Computerworld March 21, 1994 v28 n12 p91(2)

CA-Visual Objects - an overview, Vinberg, Anders, Data Based Advisor April 1994 v12 n4 p40(6)

Understanding multidatabase APIs and ODBC, North, Ken, DBMS March 1994 v7 n3 p44(11)

CA Visual Objects, Programmer Guide Vols I, II, Computer Associates International, Inc.

Oracle 7, SQL Language Reference Manual, Oracle Corporation

Q+E ODBC Driver Pack, Database Driver Reference, Intersolv Inc.

Джейм Мур (James Moore) - старший программист корпорации GAB Business Services, Inc, г. Парсипани (Parsippany), шт.Нью-Джерси, США. Имеет девятилетний опыт разработчика программ на Clipper'е и более чем двухлетний опыт работы с SQL. Последние два года является членом исполкома Technicon и президентом Clipper-клуба "New York Metro". Связаться с Дж.Муром можно по сети CompuServe (72157,2406) или по телефону (201) 993-3522.