Отправляет email-рассылки с помощью сервиса Sendsay

Программирование и готовые решения

Подписаться Бесплатная «Серебряная» новостная рассылка . Подписчиков 5.409 RSS
←   Август 2012   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


За последние 60 дней ни разу не выходила


Сайт рассылки: http://blog.leadersoft.ru
Открыта: 29-08-2000

Автор
leadersoft.ru

Статистика

5.409 подписчиков
0 за неделю
←   Все выпуски   →

Microsoft Access - программирование и готовые решения


Выпуск 14. Access Rapid Start - конструктор приложений в Access

Подписка: "Access 2003/2010 - программирование и готовые решения"
Дата: 06.08.2012
Автор: Парусников Алексей
Сайт: http://www.accessoft.ru под редакцией с http://www.leadersoft.ru
Загрузка: ARS
Получить ключ: Key_ARS

В данном цикле статей рассказывается о работе с конструктором приложений Access - Access Rapid Start. Дополнительные вопросы по этой теме Вы можете задать на форуме. Вы так же можете заказать персональную консультацию или перенос вашего проекта в ARS, связаться с автором для решения вопросов о создании программы на базе ARS - в последнем случае вы кроме готового продукта получите возможность самостоятельно его развивать.

Внимание, акция!

На 30.07.2012 назначен выход универсальной версии ARS-PRO. Основные отличия от прежних версий:

  • Добавлена возможность создавать приложения по технологии клиент-сервер. Поддержка MS SQL версий: 2000, 2005. 2007, 2008, 2009
  • Изменена форма локальных настроек – добавлены настройки для SQL-проектов и возможность разбивать настройки по группам (типам)
  • Добавлена возможность создавать шифрованные локальные настройки, доступные на чтение/изменение только через меню проекта
  • Добавлена возможность настраивать и сохранять ширины столбцов поисковых

В период с 30.07.2012 по 06.08.2012 действует скидка 50%, по которой Вы можете купить ее в интернет магазине. По окончании акции программа будет продаваться по базовой цене.

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

     Многие новички, впервые столкнувшиеся с задачей создания проекта на «настоящем сервере» представляют себе дело просто: нужно перенести таблицы и запросы на сервер, как то подключиться к ним – и тогда все будет работать «намного быстрее». В действительности можно изловчиться и сделать с точностью до наоборот – работать станет еще медленнее. Дело в том, что клиент – серверные системы имеют совершенно другую архитектуру, чем приложения на базе Microsoft Jet и нужно хорошо понимать их преимущества и недостатки.

ODBC

     К началу 1990 г. ситуация с доступом к данным реляционных БД была проблематична. На тот момент было несколько поставщиков баз данных, при этом каждый имел собственный интерфейс, что вынуждало программистов создавать отдельный код, если нужно было обратиться к разным БД из одной программы. Объединившись с ведущими разработчиками реляционных СУБД, Microsoft разработала и внедрила первый универсальный стандарт доступа к серверам реляционных баз данных – ODBC (Open DataBase Connectivity - открытый механизм взаимодействия с базами данных), который используется до сих пор в некоторых проектах. В отличие от прежних интерфейсов, он обеспечивал динамическую загрузку драйверов для работы с любыми форматами баз данных, что существенно упростило разработку и перенос приложений с одной платформы на другую. Это достигается благодаря тому, что поставщики различных баз данных унифицировали свои драйверы, реализующие конкретное наполнение стандартных функций из ODBC API с учётом особенностей их продукта. Приложения используют эти функции, реализованные в соответствующем конкретному источнику данных драйвере, для унифицированного доступа к различным источникам данных.

     Однако у ODBC были и недостатки. Во первых он предназначался только для реляционных баз данных, а ведь существует немало информации, которую не возможно структурировать согласно таким правилам, например почтовые сообщения, Web-страницы. Во вторых, доступ к драйверам ODBC происходил через API, что было не совсем удобно. Поэтому Microsoft разработала специальную высокоуровневую надстройку, включив поддержку ODBC в DAO, а так же специальные мастера создания подключений. В результате, создав подключение ODBС можно прилинковать таблицы сервера как обычные таблицы Access, что во многих случаях достаточно для того, чтобы «запустить проект».

     Итак, самый простой способ перехода с «mdb на SQL» это:

  • перенести таблицы на сервер (любым штатным мастером, входящим в состав SQL менеджера)
  • создать подключение ODBС (Файл – внешние данные – Связь с таблицами – В появившемся окне выбрать Тип файлов = Базы данных ODBC и далее по диалогу)
  • прилинковать таблицы сервера

     В результате появятся круглые ярлыки линков в виде земного шара со стрелкой. С ними можно работать как с обычными таблицами Access, используя их в качестве источника данных форм, запросов, отчетов. До появления ADP проектов так в основном и делали первые проекты SQL Server. И столкнулись с большим недостатком: крайне низкая скорость работы. Дело в том, что при таком подключении происходит двойная обработка данных: сначала через драйверы ODBC, потом через Jet. Кроме того, никак не задействованы возможности T-SQL по оптимизации запросов к данным. В итоге, если применять такой способ, то с оговорками:

  • Стараться ограничивать через TOP число отображаемых записей в списках и запросах
  • Стараться не открывать формы более чем с одной записью на редактирование (придется пересмотреть интерфейс, если используются сложные составные табличные формы)
  • Оптимизировать интерфейс с учетом минимального обращения к данным. Например, стараться не использовать составные формы, свести к минимуму количество полей со списками и т. д.

 

     С другой стороны, при таком подходе остаются доступными все возможности проектов Access, например ссылки в запросах на элементы форм, использование агрегатных функций в свойствах контролов, использование функций VBA в запросах. Но за все это придется платить отсутствием преимуществ T-SQL (если работать только через ODBC) и тормозами, заставляющими изворачиваться с интерфейсом. По этой причине подобный подход представляет интерес только для новичков и для… профи, умеющих выжать из него все достоинства и нейтрализуя недостатки другими способами доступа к данным. Но в любом варианте, «чистый ODBC подход» сейчас практически не используется в серьезных приложениях – всегда как вариант решения какой то узкой задачи.

OLE DB

     Как продолжение развития технологии доступа к данным был разработан новый интерфейс OLE DB (Object Linking and Embedding, Database). В отличие от ODBC эта технология позволяет обеспечить доступ к любым типам данных, а не только реляционным. Программа представляет собой набор интерфейсов реализованных с помощью COM (Component Object Model). Для еще большего упрощения работы, Microsoft разработала специальную библиотеку доступа к данным ADO (ActiveX Data Objects - объекты данных ActiveX), которая позволяет представлять данные из разнообразных источников от реляционных БД до текстовых файлов. Объектная модель ADO во многом похожа на привычную для разработчиков приложений Access DAO, но имеет ряд дополнительных возможностей. ARS использует именно эту технологию для работы с SQL Server как наиболее универсальную.

Сравнение архитектур файл/сервер и клиент/сервер

     Преобразовать однопользовательское (или как еще говорят «настольное») приложение Access в многопользовательское очень просто. Нужно разделить приложение на две части: файл данных (таблицы) и файл приложения (все остальное), положить файл данных в сетевой каталог с общим доступом и прилинковать из него таблицы в файле приложения. Однако такой способ работы в сети имеет ряд серьезных недостатков. Самый главный из них – при такой структуре приложения на сервере не выполняются никакие активные компоненты. При каждом подключение клиента вся обработка данных переходит на клиентское ядро Jet, а это приводит к тому, что во время выполнения запросов по сети перегоняются большие объемы данных. Например, для выборки из проиндексированной таблицы нескольких записей сначала считывается весь индекс на клиента, а затем уже фильтруются данные.

     Каждая клиентская копия Jet управляет собственным кешем физических страниц, обновлением индексов, операциями с системными таблицами и т. д. При этом синхронизации журнала транзакций не ведется и нет поддержки распределенных транзакций. Из этого вытекает другой серьезный недостаток архитектуры файл/сервер – сбой любого подключенного клиента или сетевой сбой может привести к разрушению всей базы. И хотя обычно такие сбои не приводят к фатальным последствиям, чаще слетают индексы и ключи отдельных записей, тем не менее приходится отключать всех пользователей для восстановления БД. Кроме того, Jet не решает проблем, оставшихся после аварийного завершения предыдущего сеанса на своем или другом клиенте. Подсистема обработки транзакций крайне слабо защищена от сбоев, происходящих в процессе обработки транзакции. Любая из зависших клиентских копий Jet может оставить блокировки в ldb-файле, которые в некоторых случаях могут оказаться «вечными». То есть чем больше клиентов в системе файл/сервер – тем более высока вероятность фатального сбоя во время интенсивной работы. Наконец, системный менеджмент Access так же оставляет желать лучшего.

     Из сказанного выше может сложиться впечатление, что делать сетевые приложения Access вообще не имеет смысла. Однако их делают, и довольно часто. Дело в том, что многое зависит от конкретной специфики задачи. Если одновременно подключено не более 5 – 10 клиентов, объем данных не более нескольких сотен тысяч записей в главных таблицах, интерфейс приложения оптимизирован для работы в сети, сама сеть достаточно надежна, не требуется надежной системы защиты данных – почему бы и нет. А вот когда эти параметры критически важны, стоит подумать и переходе на архитектуру клиент/сервер. Основные достоинства данной системы:

Более высокая производительность, надежность работы в сети и защита данных

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

Полноценная обработка транзакций и обеспечение целостности данных

     Большинство серверов намного строже контролируют выполнение транзакций, а скажем MS SQL Server может даже «на ходу» создавать копии критически важных данных.

Более высокий уровень системного менеджмента

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

Новые возможности сервера

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

Полезные ссылки

Интернет магазин от Leadersoft.ru
В этом магазине Вы можете купить не только готовое программное обеспечение для бизнеса, а также найти компактные решения для самостоятельного проектирования на Microsoft Access, SQL Server или ASP.NET
В избранное