Главная SQL, Новое SQL Server 2008 R2. Data-tier Application. Разработка, внедрение, модернизация
  • SQL Server 2008 R2. Data-tier Application. Разработка, внедрение, модернизация

    texas california lemon database Создание клиент-серверных приложений, даже в их простейшем двухуровневом варианте, где в качестве сервера выступает компьютер обеспечивающий доступ к общим для всех клиентов данным и к которому, собственно, и подключаются все клиенты с запросами этих самых данных, никогда не было сверхлегкой задачей. Одна из глобальных проблем стоящая перед командой берущейся за такой проект заключается в следующем. Код создающий базу данных необходимой структуры и конфигурации и наполняющий ее функционалом для удобного взаимодействия с клиентом (прежде всего хранимые процедуры и функции) пишется одним человеком, обычно называемым разработчиком баз данных (БД). И работает он, как правило, в своем окружении, со своими инструментами вроде Visual Studio. А после того как такой код написан и готов к внедрению, непосредственно внедрять и поддерживать его приходится совсем другому человеку, обычно называемому администратором БД. Помимо того что у разработчика было свое окружение (тестовое), а у администратора свое, «боевое» (production), так еще первому нечего было передать второму в качестве единого инсталляционного пакета. Для клиентской стороны давно придумали .msi-файлы работающие (с точки зрения их потребителя) в стиле «запусти-и-прощелкай-Next-до-Finish». И программа готова к работе. А вот где для администратора БД подобный пакет? Что бы сам все развернул, настроил, а перед тем еще, желательно, проверил то окружение где приложению предстоит работать согласно некоторым условиям, и сразу сказал – будет приложение серверной стороны нормально функционировать в подобных условиях или нет. А если нет – то почему, и как ситуацию исправить. А еще положение усугубляло то, что администратор-то привык работать совсем с другими инструментами, и прежде всего с SQL Server Management Studio или его аналогом для других СУБД. Т.е. наблюдался явный разрыв в точке «готовое приложение»-«установка его на рабочий сервер». Не было удобных средств передающих готовое приложение через эту точку, а два человека (или команды, в общем случае) находящиеся по разные ее стороны говорили хоть на языках и похожих, но не совпадающих. Совсем уныло все становилось когда внедренное и уже проработавшее некоторое время приложение (т.е. заполнившееся строчками данных) надо было подвергнуть модернизации (апгрейду). Тут разработчику БД приходилось даже еще сложнее, чем при создании стартовой версии. Мало того, что надо было проанализировать изменившиеся бизнес-условия (или иные факторы, повлекшие необходимость апгрейда), и что надо было представить и нарисовать новую структуру базы данных (в голове или на листе бумаги), так еще потом надо было написать код меняющий текущую структуру к структуре желаемой. Но и это не все. Допустим, написал разработчик с десяток скриптов на языке T-SQL большей частью начинающихся со слова ALTER, а также DROP и CREATE. Как теперь все это передать администратору и убедиться что все скрипты применены, да еще, возможно, важен порядок их применения? А что делать с имеющимися на текущий момент данными? Не попортят их планируемые изменения? Далее – даже при самом тщательном планировании апгрейда 100% гарантию успеха не даст никто и никогда. Соответственно – всегда что-то может пойти не так, и, как следствие, всегда должен быть разработан план «отката» к предыдущий, не модернизированной версии. Кто этот план должен разработать и предусмотреть? Разработчик? Администратор? Оба? Слишком много вопросов не имеющих однозначного ответа…

    Нельзя сказать, что с поставленными выше проблемами совсем не боролись. Боролись, но с переменным, я бы сказал, успехом. Еще в Visual Studio.NET был специальный тип проекта — Database Projects, просуществовавший и сильно эволюционировавший вплоть до самой последней, 2010-й версии студии. К нему «в пару» та же версия студии предлагает дополняющий тип проекта — Server Project.

    Далее для экономии места я буду обозначать Database Projects как DBP, а Server Project как SRVP, причем если это не отмечено особо, то возможности и функционал указанных проектов описывается по их состоянию в самой последней версии Visual Studio – 2010-й.

    Связка DBP+SRVP решает далеко не все поставленные выше вопросы, однако часть из них, несомненно, решается и, что уж совсем бесспорно, наличие этих типов проекта много лучше чем ничего.

    Теперь перейдем непосредственно к герою нашего повествования — Data-tier Application. Как должно быть ясно из предыдущих абзацев это очередная попытка решить обозначенные проблемы и предоставить унифицированный интерфейс а так же наладить наиплотнейшую кооперацию между все теми же людьми стоящими по разные стороны «болевой точки»: БД-разработчиком и БД-администратором. И, похоже, на этот раз за проблему взялись в серьез. Впервые мы имеем некоторую сущность, технологию, которую каждый из двух основных инструментов — Visual Studio и Management Studio – считает своей, «родной». Проекты нового типа можно порождать и с одной, и с другой стороны, причем их формат будет совпадать. Т.е. проект инициированный администратором (из существующей базы данных) откроется разработчиком в привычной последнему студии. Можно констатировать, что с выходом SQL Server 2008 R2 ситуация в означенной выше проблемной области кардинально меняется. Теперь в распоряжении администраторов и разработчиков есть новая сущность — приложение слоя данных (data-tier application), иногда сокращенно называемое DAC(от data acquisiton and control — сбор данных и управление). Не путайте, кстати, этот DAC с тем что dedicated administrator connection (выделенное административное подключение) — еще один термин хорошо знакомый MS SQL Server администраторам, но не имеющий ровно никакого отношения к рассматриваемой теме. Так вот тот DAC что представляет для нас интерес в рамках данной статьи и появившийся лишь в самой свежей редакции SQL Server-а — R2, является единым модулем внедрения приложения (deployment) и содержит внутри себя все элементы этого приложения: схему базы данных, объекты уровня экземпляра сервера (instance), какие-либо внешние по отношению к базе файлы и скрипты и даже, возможно, манифест определяющий требования необходимые к соблюдению для успешного внедрения приложения.

    Как мы можем получить DAC-модуль? Есть целых два пути — через новый тип проекта (data-tier application project) появившийся в Visual Studio 2010 и через мастера Extract Data-Tier Application Wizard появившегося, соответственно, в SQL Server 2008 R2. Оба пути будут нами рассмотрены более чем подробно далее.

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

    Итак, мы готовы перейти к основному содержанию статьи которое посвящено практическому применению DAC-модулей во всех 3-х фазах его жизненного цикла: создание – внедрение – модернизация. В рамках этой задачи мы создадим с нуля элементарное, но законченное приложение слоя данных, развернем его на SQL Server 2008 R2, а затем модернизируем его в Visual Studio и проведем зеркальную модернизацию на сервере. Иными словами мы попеременно будем принимать на себя роли обеих сторон участвующих в проектах подобного рода – разработчика и администратора.

    Однако прежде чем погрузиться в практику будет уместно сравнить проекты трех типов – нового, data-tier application project и двух предыдущих – DBP и SRVP. Уместность такого сравнения диктуется двумя соображениями:

    • новый тип проекта где-то вступает в конкуренцию с предыдущими; поскольку характеристики последних могут быть знакомы, как минимум, части читающей данные строки аудитории для них будет крайне интересно обзорно оценить плюсы и минусы проекта нового типа
    • новый тип проекта вступая в конкуренцию с предыдущими пока явно не готов вытеснить их полностью, а поэтому мы просто вынуждены знать сильные и слабые стороны всех 3-х «игроков» на «поляне» приложений данных, дабы осознанно выбрать правильный инструмент в конкретных условиях

    Сейчас, как не сложно догадаться, DAC как сущность и их проекты как одна из сторон этой сущности пребывают в самой начальной версии своего существования и поэтому обозначаются V1. Несомненно, что будущие версии DAC и DAC-проектов добавят этому механизму гибкости и силы однако мы будет сравнивать именно то, что есть у нас «на руках» прямо сейчас, а футуристические планы отложим на будущее.

    По тем же причинам что были указаны выше далее в тексте статьи проекты data-tier application типа будут обозначаться DACPv1. Суффикс v1 подчеркивает, что отмечаемые недостатки этих проектов существуют в их текущей, «пилотной» версии и могут быть (и с большой степенью вероятности будут) устранены в версиях последующих.

    Итак, сопоставляя DBP+SRVP vs. DACPv1 можно заключить что на текущий момент:

    • DBP призваны помочь БД-разработчикам в проектировании систем уровня предприятия. Обычно такие системы малочисленны по своему количеству, зато если суммировать число входящих в них баз, таблиц, представлений, процедур и прочих БД-объектов то мы с легкостью получим цифру с 4-мя нулями. DACPv1, с другой стороны, оптимизированы на создание большого количества легковесных приложений условно позиционируемых как приложения уровня отдела (departmental applications). Особенно хорошо с их помощью создавать и поддерживать БД-приложения с общим количеством объектов до одной тысячи, хотя чисто технически эта цифра не лимитирована.

      Примечание: в интернете встречаются заметки что 1000 объектов на DACPv1-проект именно техническое ограничение и обойти его не возможно. На самом деле это верно только по отношению к до-релизным версиям 2008 R2, в частности 2008 R2 November CTP. В релизе это ограничение убрано и оставлено только как рекомендательное и ориентировочное.

      Итого: с помощью DBP создаются «мастодонты» обеспечивающие бесперебойное течение основного бизнеса предприятия; с помощью DACPv1 — небольшие, зачастую вспомогательные, приложения решающие локальные информационные проблемы внутри отдела. Разумеется всегда надо держать в голове большую условность деления бизнеса на предприятия и отделы, но в качестве генеральной идеи по вопросу «какой инструмент когда применить» такое деление подходит очень хорошо.

    • Далее — цели распространения готовых проектов. Готовый, отлаженный и построенный (build) DBP можно развернуть на SQL Server 2005, 2008 и 2008 R2. То же что получается в результате компиляции DACPv1 (и о чем мы, конечно, будем говорить самым подробным образом) понимается исключительно 2008 R2 и, возможно, будет пониматься 2008-м сервером. Итого: пока готовые DACPv1 можно «накатывать» исключительно на самую последнюю версию SQL сервера. Что, конечно, к сильной стороне этой технологии никак не отнесешь, увы.
    • Еще один минус нового типа проекта — масштабность поддержки различных объектов (более точно — типов объектов) SQL Server-а. Как известно готовое решение на платформе MS SQL Server состоит обычно из десятков разнородных объектов: совершенно определенно там будет сама база данных, таблицы, представления, индексы для таблиц/представлений, хранимые процедуры и т.п. С большой долей вероятности там так же окажутся несколько пользователей (users) целевой БД, их роли, возможно триггеры (как DML-типа, так и DDL-типа). С некоторой долей вероятности мы можем захотеть включить в наше приложение особые имена входов (logins), оконечные точки (endpoints), триггеры уровня сервера и т.д. Кроме того, мы можем захотеть указать, что целевой сервер (более формально — экземпляр, instance) должен обладать такими-то и такими-то настройками, иначе наше решение будет работать не корректно. Так вот сочетание DBP+SRVP однозначно решает все эти вопросы — мы можем создать любой и каждый тип объекта который в принципе может существовать в мире SQL Server-а и можем проверить свойства этого сервера как того требует наша задача. В случае DACPv1 решение будет половинчатым: мы можем создавать большинство типов объектов (но не 100%!) и мы не можем проверять свойства экземпляра сервера. Последний минус отчасти компенсируется т.н. политиками отбора сервера (server selection policy) но это далеко не столь мощный механизм как проверка любого свойства сервера. Минус же первый, принципиальную невозможность работы в рамках проекта с некоторыми (справедливости ради заметим — наименее востребованными) типами объектов не компенсируется ничем, нам остается лишь уповать на развитие этой многообещающей технологии. А пока же просто иметь в виду очень важную статью в MSDN «Features Supported in Data-tier Applications» (на момент написания этих строк ее адрес http://msdn.microsoft.com/en-us/library/ee362013.aspx). Собственно, тех объектов которых НЕТ в таблице этой статьи не будет и в нашем DACPv1 решении. Например, понятно что нам не доступны XML индексы, оконечные точки, любые DDL триггеры и т.д. Причем, что характерно, в одном из визуальных представлений DACPv1 решения в Visual Studio, а именно в окне Schema View (меню View->Database Schema View) все эти «пропущенные» типы объектов есть в соответствующих под-узлах дерева иерархии объектов! Вот только добавить в эти под-узлы ничего нельзя, в их контекстном меню отсутствует пункт «Add...». Досадно, однако само наличие таких узлов вселяет уверенность в том, что когда-нибудь все будет хорошо. 🙂
    • Теперь вопрос апгрейда (модернизации) нашей БД. Совершенно ясно, что в серьезных системах (уровня как раз отдела и далее) с развертыванием разработанной, отлаженной и протестированной системы на целевом сервере работа, на самом деле, только начинается, как бы парадоксально это не прозвучало. Да — разработка системы работа большая, но вот поддержание системы «в тонусе», ее развитие и подстройка под вечно меняющиеся условия бизнеса работа еще более объемная и, как правило, значительно более продолжительная. Поэтому главный-то вопрос не «насколько удобно в том или ином инструменте/технологии писать код для новой БД?», а вопрос «предусмотрено ли что-то для плавного и без рискового перехода на новые версии той же самой БД?». И вот как раз в этом-то аспекте DACPv1 не оставляет никаких шансов ни DBP, ни SRVP. Два последних типа проекта практически не уделяли сколь-либо серьезного внимания моменту апгрейда кода БД (хотя чисто технически и делали такой апгрейд возможным). DACPv1 не просто уделяет этому вопросу повышенное внимание, а, я бы сказал, ставит момент апгрейда во главу всей инфраструктуры, что стратегически совершенно верно по причинам изложенным выше — мы гораздо чаще и большее количество раз апгрейдим код БД, нежели разрабатываем его первоначально. Разумеется, подход применяемый DACPv1 для апгрейда будет так же рассмотрен нами самым тщательным образом. И не забудьте о значительном уменьшении степени риска когда вы проводите апгрейд с помощью проекта нового типа. Теперь, если пост-фактум выяснится что апгрейд был шагом преждевременным и не обдуманным, откатиться на предыдущую, не модернизированную версию воистину «не просто, а очень просто». Простота эта касается не только структуры, но и данных если, допустим, между предыдущей версией базы и версией чей апгрейд потерпел неудачу пользователи успели на вставлять пару-другую миллионов строк записей. Все остается на месте, ничего не пропадает.

    Итого, в качестве заключительного вывода сопоставления проектов трех типов скажу что связка DBP+ SRVP предназначена для БД-администратора, который в то же время имеет уверенный опыт в разработке приложений данных. DACPv1 является инструментом «чистого» БД-разработчика, который может не обладать глубокими знаниями в администрировании SQL серверов. Ясно, что деление БД-администратор/БД-разработчик условно с момента его возникновения, а целый ряд функций требуемых в процессе создания/поддержки решения вообще не возможно однозначно приписать ни тому, ни другому в силу их ярко выраженной «пограничности». Тем не менее, в качестве грубой прикидки такое сопоставление «инструмент-пользователь инструмента» вполне уместно. В идеале же, конечно, все должны владеть всем. Это тем более оправданно, что, как уже было отмечено, DACPv1 вовсе не позиционируется как «киллер» двух других типов проектов (хотя, несомненно, конкурентом и конкурентом очень «опасным» он для них уже является). Более того из статьи «Converting between Data-tier Application Projects and Database Projects» (http://msdn.microsoft.com/en-us/library/ee241200.aspx) ясно следует, что все три типа проектов (некоторое время как минимум) будут существовать бок-о-бок. И что проект начавшийся как DBP может перетечь в DACPv1 версию, и наоборот. Упомянутая статья, кстати, хорошо поясняет что именно нужно (а что можно, но не обязательно) предпринять для подобной конвертации.

    Создание DAC модуля в Visual Studio

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

  • Инструмент разработчика: Visual Studio 2010 Ultimate edition

    (пробную версию можно загрузить: http://www.microsoft.com/downloads/details.aspx?FamilyID=06a32b1c-80e9-41df-ba0c-79d56cb823f7&displaylang=en)

  • СУБД и инструмент администратора: MS SQL Server 2008 R2 Enterprise edition и SQL Server Management Studio

    (пробную версию можно загрузить: http://www.microsoft.com/sqlserver/2008/en/us/R2Downloads.aspx)

  • Все используемое программное обеспечение является финальными версиями (release) с английским интерфейсом пользователя. MS SQL Server был проинсталлирован на машину в трех экземплярах (instance): экземпляр по умолчанию и два именованных – MSSQLSERVER2 и MSSQLSERVER3. Читателю желающему повторить все практические упражнения описанные далее рекомендуется создать такое же или максимально близкое окружение на своем тестовом оборудовании (физическом или виртуальном).

    Начнем мы, разумеется, с самого начала – с разработки приложения слоя данных. Мы уже знаем, что инициатором такого процесса может выступить как администратор БД (из SQL Server Management Studio), так и разработчик (из Visual Studio). В данном разделе мы примем на себя вторую роль, разработчика, и, соответственно, запустим Visual Studio 2010 в которой немедленно откроем окно диалога нового проекта (меню File->New->Project...). В окне слева распахнем узел Database и выберем его единственный под-узел SQL Server. Тогда в центральной части окна мы сможем выбрать нужный нам тип проекта – SQL Server Data-Tier Application. Остается лишь задать имя нового проекта что может показаться шагом достаточно формальным. В целом так оно и есть, но учтите что именно это имя получит выходной DAC-модуль, а через него новая БД на целевом сервере. Так что желательно в реальных проектах давать имя осмысленное и продуманное. В нашем учебном проекте имя вроде MyDAC представляется уместным. Финальный вид окна перед нажатием на кнопку OK показан на рис. 01.


    Рис. 01

    После короткой паузы проект будет создан и может быть просмотрен с двух «точек»: как любой проект – составная единица решения (solution), из всем знакомого окна Solution Explorer. При этом имена решения и проекта будут совпадать (MyDAC в нашем случае). Вторая обзорная «точка» позволяет посмотреть на наш проект как на будущую БД. Воспользоваться таким видом позволяет окно Schema View (меню View->Database Schema View). Работать над проектом и создавать различные БД-объекты можно из обоих окон, хотя персонально автору ближе второй вариант, окно Schema View. В нем наша будущая база выглядит очень похоже на то как она будет выглядеть на целевом сервере в окне Object Explorer инструмента SQL Server Management Studio, после того как администратор этого сервера проинсталлирует на нем DAC модуль над созданием которого мы и трудимся в настоящую минуту. В общем если вы привыкли к иерархическому дереву объектов из Object Explorer указанное окно Visual Studio для вас.

    Общая техника работы с этим окном достаточно прямолинейна: добраться до нужного типа объекта в дереве -> щелкнуть по нему правой кнопкой мыши (далее RMB, right mouse button (click) ) -> выбрать «Add...» из контекстного меню -> выбрать нужный тип объекта -> писать T-SQL скрипт создающий новый экземпляр запрошенного типа. При щелчке на некоторых типах объектов вы в контекстном меню не найдете пункта «Add...», а лишь пункт «Properties». Если коротко – такой объект нельзя добавить в DAC модуль, а более развернутое объяснение давалось в разделе «Введение» данной статьи. Давайте поработаем с указанным окном и добавим нашей базе MyDAC 3-4 разнотипных объекта.

    В окне Schema View последовательно раcпахните MyDAC->Schemas. Мы видим что база имеет одну системную схему – dbo. Добавим пару своих, для этого:RMB по узлу Schemas->"Add..."->"Schema..."->указать имя создаваемой схемы, нажать «Add». Создайте по такой методике схемы с именами Person и Production. В результате в окне Schema View у узла Schemas появятся два одноименных под-узла, а в центральной части Visual Studio будут открыты тексты двух скриптов на языке T-SQL с теми же именами и с расширениями .schema.sql (это обычный sql-скрипт хорошо знакомый всем читателям). Именно такими командами при инсталляции будущего DAC модуля на целевой сервер будут созданы указанные объекты. Мы, как разработчики, разумеется, вольны подправить текст любого такого скрипта как посчитаем нужным, но в данном случае особо исправлять/дополнять нечего, оставляем как есть. Вместо этого обратим внимание, что в ярлычках обоих файлов после расширения «sql» значится «not connected» (рис. 02). Это пример т.н. offline development experience (опыта отсоединенного программирования). Такое название было дано потому, что судя по окну Schema View у нас уже как бы есть база MyDAC с, как минимум, 3-мя объектами: dbo, Person, Production. В реальности мы никуда не подключены и никакой сервер эту базу не обслуживает, она есть совершенно «виртуально», только в рамках нашего проекта.


    Рис. 02

    Теперь добавим пару таблиц. Распахните недавно появившийся в нашем рабочем окне узел Person->RMB по его под-узлу Tables->"Add..."->"Table..."->вводим имя таблицы, Customer в нашем случае, «Add». Получаем примитивный скрипт Customer.table.sql, создающий таблицу из двух колонок. Это не совсем то что нам нужно, мы тоже будем в нашем проекте использовать весьма не сложные таблицы, но все же не до такой степени примитивные. Поэтому стираем весь нагенеренный код этого скрипта и пишем более-менее похожий на реальный, к примеру такой:

    CREATE
    TABLE [Person].[Customer]

    (

    CustomerID int IDENTITY(1,1) NOT
    NULL,

    FullName nvarchar (50) NULL,

    EmailAddress nvarchar (50) NULL,

    [Password] nvarchar (50) NULL,


    CONSTRAINT [PK_Customers] PRIMARY
    KEY
    NONCLUSTERED (CustomerID)

    )

    Обратите внимание, что в отличии от Management Studio объекты БД в Visual Studio создаются исключительно T-SQL кодом, никаких визуальных дизайнеров таблиц, представлений и прочего.

    Если после предыдущей правки мы распахнем под-узел Tables узла Person то обнаружим что первый содержит новый объект – Customer. Точно так же создайте в схеме Production две таблицы с именами Category и Product. Предлагаемые для их создания скрипты замените на

    CREATE
    TABLE Production.Category

    (

    CategoryID int IDENTITY(1,1) NOT
    NULL,

    CategoryName nwarchar (50) NULL,


    CONSTRAINT [PK_Categories] PRIMARY
    KEY
    NONCLUSTERED (CategoryID)

    )

    и

    CREATE
    TABLE Production.Product

    (

    ProductID int IDENTITY(1,1) NOT
    NULL,

    CategoryID int NOT
    NULL,

    ModelNumber nvarchar (50) NULL,

    ModelName nvarchar (50) NULL,

    ProductImage nvarchar (50) NULL,

    UnitCost money NOT
    NULL,

    Description nvarchar (3800) NULL,


    CONSTRAINT [PK_Products] PRIMARY
    KEY
    NONCLUSTERED (ProductID),


    CONSTRAINT [FK_Prod_Categ] FOREIGN
    KEY (CategoryID) REFERENCES Production.Category

    )

    соответственно.

    Если внимательные читатели заметят что в предпоследнем скрипте имя типа, вообще-то, пишется nvarchar а не так как написано, через 'w', то будут совершенно правы. Однако пока оставьте все как есть, с ошибкой. Смысл этого действия будет ясен из дальнейшего рассказа.

    Ну и с демонстрационными целями добавим в схему Production хранимую процедуру. По аналогии с предыдущими шагами распахиваем Schemas->Production->Programmability. Далее RMB на под-узле «Stored Procedures»->"Add..."->"Stored Procedure..."->GetProductByID (имя создаваемой процедуры) ->"Add". Ожидаемо, получаем скрипт GetProductByID.proc.sql. Стираем, вставляем нужные нам команды:

    CREATE
    Procedure Production.[GetProductByID](@ProductID int)

    AS

    SELECT * FROM Production.Product WHERE ProductID=@ProductID

    Кстати, если в предыдущем скрипте вы начнете набивать его руками вместо копирования из прилагаемого к статье файла исходного кода (что чаще всего и бывает при реальном программировании), то набрав в последней строке скрипта «...FROM Production» и нажав точку вы получите подсказку IntelliSense как показано на рис. 03, и это при том, что еще ничего не только не компилировалось, а даже не сохранялось (обратите внимание на звездочки в ярлыках скриптов)!

    Рис. 03

    Теперь для тестовых целей не плохо бы создать что-либо на уровне сервера. Распахнув в нашем окне узел Serevr Level Objects и прощелкав правой кнопкой мыши все его под-узлы с некоторой досадой обнаруживаем что нам доступен лишь один вид объекта – имена входов (logins). Ну, стало быть выбирать не приходится: MyDAC->Serevr Level Objects->Security->RMB по узлу Logins->"Add..."->"Login..."->'Guest' (имя нового объекта) -> «Add». Получаем скрипт Guest.login.sql. В нем почти все правильно, за исключением отсутствующего имени компьютера. Подправьте скрипт вставив это имя перед именем входа. Например, на моей тестовой машине с именем, напомню, WIN2008 окончательный вид скрипта был таким:

    CREATE LOGIN [WIN2008\Guest] FROM WINDOWS

    Учетная запись Guest является встроенной (built-in) и присутствует в любой операционной системе Windows-платформы. Обычно она находится в отключенном (disabled) состоянии однако для наших экспериментов это совершенно безразлично, мы хотим лишь убедиться в принципиальной возможности создания объектов уровня сервера новым типом приложения, а создавать имена входов из отключенных учетных записей можно.

    Наконец, что бы логически завершить наш проект создадим под новое имя входа пользователя (user) нашей базы. Полагаю принципы создания объектов теперь совершенно ясны, поэтому буду краток: MyDAC->Security->RMB по узлу Users->"Add..."->"User..."->'MyGuest' (имя нового объекта) -> «Add».

    Мы используем имя MyGuest вместо просто Guest т.к. последний является системным пользователем и уже (неявно) присутствует в нашей базе (как, впрочем, и в любой другой созданной на платформе MS SQL Server).

    Подправляем скрипт MyGuest.user.sql:

    CREATE
    USER [MyGuest] FROM LOGIN [WIN2008\Guest]

    Все! Мы готовы к компиляции и получению DAC модуля. Наш проект, на текущий, момент состоит из:

    • базы данных — MyDAC
    • двух схем — Production и Person
    • трех таблиц — Category, Product и Customer
    • по одному экземпляру — хранимой процедуры (GetProductByID), имени входа (WIN2008\Guest) и пользователя (MyGuest)

    Итого 9 разнородных объектов, для тестовых целей достаточно. Сохраним все что мы наработали: File->Save All. Компиляция запускается совершенно стандартно – F6/Build->Build Solution. Ага, не все так гладко, нам любезно сообщают что типа nwarchar не существует, с чем не поспоришь:

    Error    1    SQL03006: Column: [Production].[Category].[CategoryName] has an unresolved reference to Sql Type [dbo].[nwarchar].

    Двойной клик по указанной выше строке в окне Error List и мы переносимся к виновнику переполоха – 4-й строке в скрипте Category.table.sql. Подправляем 'w' на 'v' и перезапускаем компиляцию. На этот раз итогом является обнадеживающее сообщение в строке статуса студии – Build succeeded. В общем-то, к этому моменту у нас уже есть на руках файл для передачи его администраторской команде, однако я предлагаю не торопиться и потратить еще 5-10 минут на изучение свойств нашего проекта, тем более там есть что обсудить. Откроем окно этих свойств: Project->MyDAC Properties... . Свойств, как можно видеть, достаточно много и они разбиты на 5 страниц. Обсудить абсолютно каждую настройку в рамках статьи было бы занятием малопродуктивным, а поэтому сосредоточимся на главных.

    Итак, на первой закладке Project Settings наверно самым интересным свойством (в свете будущей модернизации которая обязательно случится в рамках данной статьи) является номер версии (поле Version). Назначение этого поля самоочевидно (номер версии нашего приложения), но от этого не менее важно. Ведь обычно именно по этому номеру администратор будет оценивать передали ли ему DAC модуль с новой версией приложения или уже с существующей на управляемом им сервере. Просто с целью демонстрации допустим мы хотим начать не с традиционного 1.0.0.0 а сразу с 1.1.1.1. Введите это число в поле Version и затем перейдите на закладку 'Deploy'. Здесь есть интересное поле Destination connection string, изначально пустое. Зачем оно если вроде как новый тип проекта поощряет работу в отсоединенном (offline) режиме, а развертыванием (тот самый Deploy) занимается НЕ разработчик? Тут идея такая – финальным развертыванием на production сервере занимается действительно администратор, но, наверно, в процессе разработки проекта программист захочет проводить тестовые развертывания на какой-то пробный (обычно локальный) сервер. Нет проблем выполнить эту процедуру точно так же как ее выполняет администратор (см. раздел Внедрение (развертывание) готового DAC модуля ниже), т.е. открыть SQL Server Management Studio, запустить мастера установки DAC модулей и т.д. Но можно и избрать «короткий путь» — заполнить через кнопку 'Edit...' обсуждаемое поле (потребуется указать только целевой сервер), а потом просто выбирать Build->Deploy Solution, в результате чего проектируемое решение будет автоматически перенесено на указанный сервер и там развернуто. Удобно при цикличной разработке и для тестирования промежуточных версий. Замечу что если строка подключения пустая (как в нашем проекте) выбор пункта меню Deploy Solution приводит к ошибке, что вполне логично – куда разворачивать-то решение хотим? Так же отмечу что компиляция (build) и перекомпиляция (rebuild) решения никогда не приводят к его развертыванию вне зависимости от заполнености поля Destination connection string. Развертывание, даже такое «автоматическое», всегда запускается принудительно, через обозначенный пункт меню. И, наконец, перед «авто-развертыванием» (если Destination connection string заполнено) проект в обязательном порядке компилируется, не обязательно запускать этот шаг отдельно.

    Мы не будем заниматься «автоматическим» развертыванием, а посему оставляем Destination connection string пустым и переключаемся на последнюю закладку, 'Code Analysis'. Эта закладка полностью посвящена одной функции поддерживаемой студией – статическому анализатору кода, причем по умолчанию он выключен. Не сказать что указанный функционал является именно новым в полном смысле этого слова для проектов баз данных в Visual Studio 2010. Был он и в предыдущих версиях, однако по мнению автора этих строк статус серьезного инструмента он обрел лишь в прошлой, 2008-й студии. Поэтому вполне возможно не все читатели успели познакомиться с этим замечательным, на мой взгляд, помощником разработчика и мы можем позволить себе задержаться на этой закладке свойств DAC-проекта чуть дольше. Отмечаем опцию 'Enable Code Analysis on Build', сохраняем настройки (Ctrl+S) и перезапускаем компиляцию (Build->Rebuild Solution). Ошибкам, разумеется, с предыдущей компиляции взяться было неоткуда, мы тексты скриптов не трогали. Зато появилось одно предупреждение, которое можно видеть в том же окне что и ошибки — Error List, только не забудьте в нем переключиться на соответствующую вкладку (рис. 04).


    Рис. 04

    Двойной клик по предупреждению снова переносит нас к проблемному месту. А суть проблемы – употребление метасимвола звездочка вместо нормального перечисления колонок требуемого результирующего набора. Не вижу смысла агитировать за полное и безоговорочное исключение звездочек в любом промышленном коде, для более-менее искушенных администраторов и разработчиков это самоочевидно. Поэтому подумаем как исправить эту пусть и не ошибку но очень серьезный недочет. Во-первых, заметим, что если «завесить» в редакторе мышиный курсор над звездочкой то всплывающая подсказка расскажет нам обо всех колонках этим метасимволом скрываемыми (рис. 05).


    Рис. 05

    Во-вторых, нашим первым побуждением будет просто стереть звездочку и набить видимый в подсказке список через запятую. Это, конечно, сработает, но есть способ много эффективней, называется он рефакторинг кода. Работает примерно так:Data->Refactor->Expand Wildcards... (положение курсора в коде не важно). В открывшемся окне лучше щелчком мыши подсветить последнюю строку в верхней панели Expand Wildcards, тогда в нижней панели Preview changes планируемые изменения будут выделены (рис. 06).


    Рис. 06

    Нажатие кнопки Apply завершает весь процесс. Перекомпиляция подтверждает отсутствие на этот раз и ошибок, и предупреждений.

    Я рекомендую самостоятельно изучить подменю Data->Refactor дабы узнать какие еще «вкусности» в плане рефакторинга T-SQL кода приготовили нам разработчики новой версии студии, а мы давайте еще раз вернемся в закладку настроек проекта где была включена опция 'Enable Code Analysis on Build'. Кстати, «короткий путь» к этой вкладке Data->Static Code Analysis->Configure... . В списке 'Rules' перечислены все правила о которых осведомлен анализатор кода. Для любого из них (или даже сразу для всей группы правил) можно отметить галочкой колонку 'Treat Warning as Error'. Тогда соответствующее предупреждение (вроде того, которое было нами получено касательно применения в коде звездочки) будет переведено в категорию ошибок. Это не позволит разработчику просто игнорировать его и продолжить работу с выходным DAC модулем.

    Закроем окно свойств проекта и обратимся к двум файлам находящимся в папке Properties нашего проекта (окно Solution Explorer). Начнем с первого, Database.sqlsettings. По двойному клику по нему открывается довольно-таки неприглядный интерфейс редактирования настроек в нем хранящихся. Этот файл содержит поднабор свойств базы данных который можно видеть в полном варианте в SQL Server Management Studio (RMB по имени любой базы в окне Object Explorer->Properties->закладка Options->категория Miscellaneous). Почему из множества свойств базы была выбрана только эта категория, да еще в урезанном варианте, думаю не ответит никто. Идея стоящая за этим файлом понятна – ведь на целевом сервере по итогу будет создана база данных одноименная разрабатываемому нами приложению. Было б неплохо иметь возможность установить пару-другую опций для нее. Этот файл позволяет проделать именно такую операцию, однако на мой персональный взгляд количество опций им обслуживаемых должно быть значительно расширено.

    Откроем (тоже двойным кликом) второй файл папки Properties — ServerSelection.sqlpolicy. Тут пользовательский интерфейс уже куда как более «вменяем» и производит благоприятное впечатление. Идея стоящая за этим файлом такая: уже совсем скоро мы передадим выходной DAC модуль администратору и тот попробует развернуть его на целевом сервере. Мы можем потребовать что бы сервер был не ниже версии 2008 R2 (на текущий момент не очень актуально, DAC модули и так инсталлируются только на эту версию сервера) или что бы редакция сервера была именно Enterprise и не иначе. Иными словами мы можем задать ту самую политику отбора сервера (server selection policy) упомянутую в статье ранее. Если инсталляционный пакет в процессе развертывания заметит одно или более нарушений этой политики администратор получит соответствующее уведомление и сможет развертывание прекратить. Или, напротив, продолжить установку пакета, но уже осознавая что делает он это на свой страх и риск, если у него есть основания полагать что нарушение политики не носит критического характера. Давайте, для тестовых целей, зададим в нашей политике пару условий которые заведомо будут нарушены. К примеру в списке 'Facet properties' можно отметить галочкой пункт Edition и в возникшем вслед за этим окне Edit Values выбрать сравнение 'is not equal to', а в поле 'Value' ввести 'Enterprise Edition' (не забудьте напечатать одинарные кавычки тоже!). Нажимаем OK и первое условие политики отображается в списке 'Edit the condition', где его, кстати, можно редактировать. Но нас редактирование не интересует и вместо этого давайте отметим в списке 'Facet properties' второй пункт, VersionMajor. В окне Edit Values выберем сравнение 'is less than' и в поле 'Value' введем 10. Нажатием OK подтвердим второе положение нашей политики – целевой сервер должен иметь главный номер версии меньше 10-ти (у SQL Server 2008 / 2008 R2 он как раз равен этому числу). Нажатием Ctrl+S фиксируем нашу политику из двух пунктов: редакция сервера НЕ Enterprise, версия – ДО SQL Server 2008 (в конфигурации компьютера у автора оба положения нарушены).

    Вскользь упомяну еще о двух файлах нашего проекта уже не имеющих отношений ни к каким настройкам. Найти их можно в окне Solution Explorer, распахивая последовательно узлы MyDAC->Scripts->Pre-Deployment либо MyDAC->Scripts->Post-Deployment. В них и находятся файлы Script.PreDeployment.sql и Script.PostDeployment.sql соответственно. В них можно написать любые T-SQL команды и они выполнятся до (Pre-) или после (Post-) момента когда начнутся/закончатся создаваться объекты нашего приложения. Удобно для работы с теми вещами, с которыми работа «напрямую» из проекта типа SQL Server Data-Tier Application не предусмотрена. Что бы не переусложнять нашу тестовую практику мы работать с этими скриптами не будем, а по умолчанию в них нет ничего кроме комментария.

    Теперь заметим, что наш проект – это полноценный студийный проект, а значит он может быть скомпилирован в двух (как минимум) конфигурациях: отладочной (debug) и финальной (release). Что бы продолжить разыгрываемый нами сценарий допустим мы уже отладили наше приложение, протестировали его в нашем локальном окружении, выяснили и утвердили на уровне политики отбора те сервера на которых оно сможет работать нормально и готовы передать выходной DAC модуль команде администраторов SQL Server-а. Тогда уместно выбрать в меню Build->Configuration Manager... и в одноименном окне выставить финальную (release) конфигурацию. И, наконец, запустить финальную перекомпиляцию, Build->Rebuild Solution. Все! Нам осталось откуда-то с диска забрать выходной файл для передачи его администраторской группе целевого SQL Server-а. Полный путь к этому файлу будет <корневая_папка_проектов> \ <имя_решения> \ <имя_проекта> \ sql \ release \ <имя_проекта>.dacpac. Например в моем окружении требуемый файл нашелся по пути c:\VSprojects\MyDAC\MyDAC\sql\release\MyDAC.dacpac, где c:\VSprojects есть корневая папка для всех моих проектов. Так же не забудьте, что я переключился на финальную конфигурацию сборки. Если бы конфигурация оставалась отладочной файл бы нашелся почти по тому же пути только вместо release в нем было бы слово debug. Легко заметить, что установочный пакет для приложений нового типа имеет расширение .dacpac, от, очевидно DACpac (ket). «Забираем» этот файл и примеряем на себя вторую роль участника проекта – администратора целевого SQL Server-а.

    Внедрение (развертывание) готового DAC модуля

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

    Итак, мы администраторы SQL Server и получили (допустим по e-mail) файл MyDAC.dacpac с некоторой сопроводительной запиской. Мы в общих чертах знаем в чем назначение этого файла и понимаем что это – инсталляционный пакет для приложения нового типа. Однако прежде чем мы перейдем к процессу инсталляции как таковому взглянем на файл с расширением .dacpac поближе.

    Для последующих шагов нашей практики расположение файла MyDAC.dacpac роли не играет, он может оставаться в той же директории куда его поместила при компиляции Visual Studio (и где он находится с файлами исходного кода из архива MyDAC_v_1_1) или, по желанию, вы можете переместить/скопировать его в любую папку и на любой диск.

    При ближайшем рассмотрении выясняется, что файл этот – не что иное как .zip-архив с замененным расширением. Разумеется он без проблем «вскрывается» любым «zip-читающим» инструментом. Но есть способ и того проще. На компьютерах с установленной Visual Studio 2010 и/или MS SQL Server 2008 R2 расширение .dacpac является зарегистрированным и операционная система сама знает что с этим файлом можно/нужно делать (связанное приложение – DacUnpack.exe обычно размещаемое в папке c:\Program Files\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\). Можно предположить что двойной клик по подобному файлу запустит его инсталляцию (по аналогии с .msi-файлом) но это было бы неосмотрительным решением. Все же запускать что-либо (а уж особенно если это «что-то» T-SQL код) на сервер с «живыми» данными просто по двойному клику, это, согласитесь, рискованно. Поэтому инсталляция запускается все же принудительно, через мастера (о чем у нас речь впереди). А по двойному клику срабатывает операция значительно менее потенциально деструктивная – мы всего лишь получаем предложение распаковать кликнутый .dacpac-файл в любую папку по нашему выбору (рис. 07).


    Рис. 07

    Нажатие кнопки Unpack приводит к ожидаемому результату, при этом никакие zip-инструменты нам не нужны. В результате в целевой папке оказываются все .sql-скрипты упакованные в исследуемом модуле, а так же .xml файлы содержащие метаданные и вспомогательную информацию. Бегло просмотрев все это богатство администратор может принять решение об установке (или, напротив, о не установке) .dacpac-файла полученного из не доверяемого источника. Если же планируется модернизация установленного ранее приложения, то файл DacMetadata.xml в своем элементе <Version> содержит номер версии приложения из только что распакованного файла. Можно проконсультироваться с ним дабы убедиться что мы получили именно новую версию.

    Итак, убедившись что мы определенно хотим проинсталлировать полученный пакет, открываем Management Studio от SQL Server 2008 R2. Подключаемся обычным порядком к целевому серверу (более точно – к его экземпляру) и в окне Object Explorer, распахиваем узел Management. Далее делаем щелчок правой кнопкой мыши по под-узлу Data-tier Applications и выбираем 'Deploy Data-tier Application...' из контекстного меню (рис. 08).


    Рис. 08

    Запускается мастер (wizard) установки .dacpac-пакетов. Первая страница информационно-ознакомительная, по желанию читаем, возможно помечаем опцию пропуска этой страницы в будущем ('Do not show this page again'), Next >. Страница номер 2 тоже трудностей не вызывает – с помощью кнопки 'Browse...' указываем инсталляционный пакет (MyDAC.dacpac в нашем случае). После выбора пакета на той же странице отобразятся имя готового к инсталляции приложения и, что важно при модернизации, его версия. Обратите внимание, что сейчас этот номер 1.1.1.1, как мы и задали в свойствах проекта в предыдущем разделе. Если все верно — Next >. А вот на третьем шаге нас ждет небольшой сюрприз, правда ожидаемый. Помните мы внедрили в наш пакет политику отбора целевых серверов из двух условий? Вот она и сказала свое веское слово (рис. 09).


    Рис. 09

    Видно, что как мы и запланировали, оба условия нарушены и двигаться далее не возможно. Разумным шагом здесь было бы нажать Cancel и проконсультироваться с разработчиком для выяснения критичности нарушений, благо отчет однозначно показывает «как должно быть» и «как оно на самом деле». Мы же можем абсолютно уверенно отмечать вариант 'Ignore policy violations' (на рис. 09 это уже сделано) тем самым разблокируя кнопку Next > и двигаясь с помощью нее далее. На шаге следующем, Update Configuration, мы вряд ли захотим что либо менять, т.к. тут потенциально можно изменить имя инсталлируемого DAC-приложения, а вместе с ним, и имя базы данных создаваемой «под» него. Но, очевидно, разработчику более уместно задать эти значения, мы почти всегда согласимся с его выбором. С помощью двух кнопок 'Browse...' можно изменить папки для файла данных и файла журнала транзакций для новой базы. Тоже сомнительно что пути по умолчанию нам придутся не по душе, поэтому просто Next >. Шаг Summary просто итожит все что мы сделали до сих пор, поэтому снова просто Next >. Наконец шаг финальный, Deploy DAC, осуществляет физическую инсталляцию приложения и создает новую базу. Мы можем следить за этим процессом, т.к. его основные шаги выводятся в окне отчета (рис. 10).


    Рис. 10

    Нажатие на Finish завершает работу мастера.

    Итак – давайте посмотрим, что у нас появилось в результате на нашем экземпляре сервера.

    Перво-наперво в узле Management->Data-tier Applications у нас появилось само приложение, MyDAC (рис. 11). Его контекстное меню позволит проводить две важнейшие операции – модернизировать указанное Data-tier приложение и удалять его с сервера. Обе операции будут рассмотрены нами далее. А еще с такими приложениями можно проводить интереснейший процесс – мониторить потребление ими ресурсов сервера и, анализируя графики потребления, делать выводы о намечающихся тенденциях, как благоприятных, так и не очень. Такой мониторинг осуществляется с привлечением утилиты (более формально – управляющая функция, еще одна новинка мира R2 SQL Server-а) по имени SQL Server Utility. В виду объемности вопроса процесс этот не будет рассматриваться в данной статье совсем, но автор надеется что у него достанет творческих сил и времени на отдельный очерк именно об этом нововведении. Пока же ограничимся лишь инсталляцией/модернизацией/удалением Data-tier приложений. Так же замечу, что наличие под-узла MyDAC в Data-tier Applications (как на рис. 11) означает что одноименное приложение должным образом зарегистрировано в системной базе msdb и если необходимость в нем отпадет мы должны именно де-инсталлировать это приложение, а не просто удалить поддерживающую его базу.


    Рис. 11

    Во-вторых, у нас появилось требуемое нашему приложению имя входа, WIN2008\Guest (рис. 12).


    Рис. 12

    В-третьих, и самое главное, появилась база данных одноименная приложению (рис. 13)


    рис. 13

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

    Попробуем инсценировать работу пользователей с новым приложением и, прежде всего, нас будет интересовать наполнение таблиц строками. Вставьте во все 3 таблицы нашей базы по 2-3 строки произвольного содержания. Можно воспользоваться таким скриптом:

    USE [MyDAC]

    GO

    SET
    IDENTITY_INSERT [Person].[Customer] ON

    INSERT [Person].[Customer] ([CustomerID], [FullName], [EmailAddress], [Password]) VALUES (1, N'Nick Jagger', N'nick@abcd.com', N'nick')

    INSERT [Person].[Customer] ([CustomerID], [FullName], [EmailAddress], [Password]) VALUES (2, N'Rob Palmer', N'rob@abcd.com', N'rob')

    INSERT [Person].[Customer] ([CustomerID], [FullName], [EmailAddress], [Password]) VALUES (3, N'Ann Smith', N'ann@abcd.com', N'ann')

    SET
    IDENTITY_INSERT [Person].[Customer] OFF

    SET
    IDENTITY_INSERT [Production].[Category] ON

    INSERT [Production].[Category] ([CategoryID], [CategoryName]) VALUES (1, N'Sport')

    INSERT [Production].[Category] ([CategoryID], [CategoryName]) VALUES (2, N'Computer')

    INSERT [Production].[Category] ([CategoryID], [CategoryName]) VALUES (3, N'Food')

    SET
    IDENTITY_INSERT [Production].[Category] OFF

    SET
    IDENTITY_INSERT [Production].[Product] ON

    INSERT [Production].[Product] ([ProductID], [CategoryID], [ModelNumber], [ModelName], [ProductImage], [UnitCost], [Description]) VALUES (1, 1, N'SP1', N'Pump', NULL, 12.9500, N'Nice pump')

    INSERT [Production].[Product] ([ProductID], [CategoryID], [ModelNumber], [ModelName], [ProductImage], [UnitCost], [Description]) VALUES (2, 2, N'CO1', N'Motherboard', NULL, 89.9900, N'Nice motherboard')

    INSERT [Production].[Product] ([ProductID], [CategoryID], [ModelNumber], [ModelName], [ProductImage], [UnitCost], [Description]) VALUES (3, 2, N'CO2', N'HardDisk320G', NULL, 99.9700, N'Nice HDD')

    INSERT [Production].[Product] ([ProductID], [CategoryID], [ModelNumber], [ModelName], [ProductImage], [UnitCost], [Description]) VALUES (4, 1, N'SP2', N'Helmet', NULL, 10.0700, N'Nice helmet')

    INSERT [Production].[Product] ([ProductID], [CategoryID], [ModelNumber], [ModelName], [ProductImage], [UnitCost], [Description]) VALUES (5, 3, N'FD1', N'Bread', NULL, 2.2000, N'Nice bread')

    INSERT [Production].[Product] ([ProductID], [CategoryID], [ModelNumber], [ModelName], [ProductImage], [UnitCost], [Description]) VALUES (6, 3, N'FD2', N'Milk', NULL, 1.8900, N'Nice milk')

    SET
    IDENTITY_INSERT [Production].[Product] OFF

    Можете, по желанию, опробовать работу хранимой процедуры GetProductByID хотя, полагаю, общий итог ясен – мы получили полноценную базу данных с типичным набором объектов с которыми мы (и пользователи нами поддерживаемые) работаем самым обычным порядком.

    Теперь, допустим, по причине изменившихся бизнес-требований приложение MyDAC потребовало уточнений/изменений/исправлений и т.п. В общем требуется его модернизация. Модернизацию, в общем случае, осуществляет (на уровне изменения кода) разработчик. А поэтому закрываем пока Management Studio и снова принимаем на себя первую роль, роль разработчика.

    Модернизация Data-tier приложения со стороны разработчика

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

    Итак – мы снова готовы вернутся к работе с Visual Studio 2010. Откроем ее и загрузим текущий вариант приложения MyDAC с номером версии, как вы помните, 1.1.1.1. File->Open->Project/Solution... и указываем на файл решения — MyDAC.sln. Решение загружается в его текущем состоянии, спецификации и техническая документация на модернизацию приложения считаем у нас на руках. Ознакомимся с заданием:

    1. Удалить таблицу Person.Customer
    2. В таблицу Production.Product добавить колонку isOnPromotionNow, тип bit. Указанная колонка не должна позволять NULL значений.
    3. Создать представление (view) Production.AllCategoryAndProduct. Указанное представление использует обе таблицы схемы Production и выводит все категории товаров, все товары в этих категориях, цену за единицу каждого товара, и проводится ли в данный момент рекламная акция для каждого товара (новая колонка isOnPromotionNow).
    4. Удалить пользователя базы MyGuest.
    5. Удалить имя входа WIN2008\Guest.

    Приступаем к реализации вышеозначенных изменений. Самое простое – удалять. Начнем с этого, для чего в привычном уже окне Schema View найдем в дереве первый удаляемый объект (MyDAC->Schemas->Person->Tables->Customer) сделаем RMB по имени удаляемой таблицы и выберем Delete. Подтверждаем наше намерение и таблица убрана из проекта. Проделаем ту же процедуру с пользователем (MyDAC->Security->Users->MyGuest) и с именем входа (MyDAC->Server Level Objects->Security->Logins->WIN2008\Guest).

    Теперь внесем изменение в структуру таблицы Production.Product, для чего переключимся в окне редактора на ярлык скрипта создающего эту таблицу (Product.table.sql) или откроем этот скрипт двойным кликом по узлу Product в дереве окна Schema View. Опишем новую структуру таблицу которая, за исключением одной строки (выделенной жирным ниже), дублирует структуру текущую.

    CREATE
    TABLE Production.Product

    (

    ProductID int IDENTITY(1,1) NOT
    NULL,

    CategoryID int NOT
    NULL,

    ModelNumber nvarchar (50) NULL,

    ModelName nvarchar (50) NULL,

    ProductImage nvarchar (50) NULL,

    UnitCost money NOT
    NULL,

    Description nvarchar (3800) NULL,

    isOnPromotionNow bit NOT
    NULL,


    CONSTRAINT [PK_Products] PRIMARY
    KEY
    NONCLUSTERED (ProductID),


    CONSTRAINT [FK_Prod_Categ] FOREIGN
    KEY (CategoryID) REFERENCES Production.Category

    )

    Обратите внимание, что мы не думаем в стиле «как мы будем менять» (ALTER TABLE... и т.п.), а в стиле «что нужно получить в итоге». Второй подход гораздо продуктивнее в смысле возможности сосредоточиться на решении именно бизнес-задач.

    Осталось создать представление. Идем знакомым путем: MyDAC->Schemas->Production->Views, делаем щелчок правой кнопкой по этому узлу, Add->View... ->'AllCategoryAndProduct' (имя создаваемого объекта) ->кнопка 'Add'. Правим скрипт:

    CREATE
    VIEW [Production].[AllCategoryAndProduct]

    AS

    SELECT Production.Category.CategoryName, Production.Product.ModelName, Production.Product.UnitCost, Production.Product.isOnPromotionNow

    FROM Production.Category INNER
    JOIN Production.Product ON Production.Category.CategoryID = Production.Product.CategoryID

    Теперь, дабы дать знать всем заинтересованным лицам что DAC пакет который мы собираемся компилировать является развитием текущего проекта «продвинем» номер версии. Открываем свойства проекта (Project->MyDAC Properties...), переходим на закладку 'Project Settings' и в поле 'Version' меняем текущие 1.1.1.1, на, скажем, 2.2.2.2.

    Наконец, представим себе что мы, как разработчики, понимаем – сделанные нами изменения еще более ужесточили требования к целевому серверу, и мы должны добавить третий пункт в добавок к двум существующим в нашей текущей политике отбора серверов. Окно Solution Explorer, MyDAC->Properties, двойной клик по ServerSelection.sqlpolicy. В редакторе редактирования политик, в панели 'Facet properties' отмечаем свойство 'Platform'. В появившемся диалоге 'Edit Values' выбираем тип сравнения 'is not equal to' и требуем что бы платформа была НЕ 'NT INTEL X86' (снова кавычки!). В моем случае платформа именно такая, так что я готовлюсь при апгрейде приложения получить целых 3 предупреждения.

    Сохраняем все что мы проделали до текущего момента (File->Save All), убеждаемся что наш проект по прежнему настроен на производство release версии выходного пакета (Build->Configuration Manager...) и запускаем перекомпиляцию, Build->Rebuild Solution. Убеждаемся в сообщении Rebuild All succeeded в строке статуса студии и закрываем последнюю. Находим на привычном месте обновленный файл MyDAC.dacpac, «отправляем» его администратору сервера и принимаем на себя эту роль дабы выполнить вторую фазу модернизации – ее применение на стороне сервера. Напоследок отметим, что новая версия состоит из 7-ми разнородных объектов:

    • база данных — MyDAC
    • две схемы — Production и Person
    • две таблицы – Category и Product
    • по одному экземпляру – хранимой процедуры (GetProductByID) и представления (AllCategoryAndProduct)

    Модернизация Data-tier приложения со стороны администратора

    Итак – мы с Вами вновь администраторы SQL Server-а и только что получили по электронной почте письмо с вложенным файлом MyDAC.dacpac и с поясняющей запиской что это есть инсталляционный пакет для приложения версии 2.2.2.2. Что ж, попробуем проапгрейдиться.

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

    Открываем Management Studio, подключаемся к тому экземпляру на котором мы в прошлых разделах статьи установили наше приложение, распахиваем Management->Data-tier Applications, делаем щелчок правой кнопкой мыши по под-узлу с именем приложения (MyDAC) и выбираем 'Upgrade Data-tier Application...' из контекстного меню (рис. 14).


    рис. 14

    Запускается мастер весьма похожий на виденный нами в разделе «Внедрение (развертывание) готового DAC модуля» где мы впервые инсталлировали наше приложение. Так же как и там первая страница Introduction является чисто ознакомительной, читаем, Next >. На странице второй 'Select Package' с помощью кнопки 'Browse...' выбираем «полученный» нами от разработчика файл MyDAC.dacpac. Сразу после выбора, на той же странице, глядя на значение в поле 'Version' убеждаемся что пакет действительно содержит новую, улучшенную версию приложения – 2.2.2.2. Это хорошо, поэтому Next >. Страница 'Review Policy' выдает ожидаемый результат – три ошибки, две от предыдущей версии и одну разработчик добавил при модификации кода (рис. 15).


    рис. 15

    Снова разумным шагом здесь было бы нажать 'Cancel' и проконсультироваться с разработчиком для выяснения критичности нарушений. Мы же опять отмечаем 'Ignore policy violations' тем самым разблокируя кнопку Next > и двигаясь с помощью нее далее. Теперь нас ждет страница которой не было в мастере проводящем первоначальную инсталляцию приложения, 'Detect Change'. Как легко видеть она не позволяет нам сделать ничего, кроме как нажать Next > но содержит сообщение 'The database MyDAC has not changed', (рис. 16).


    рис. 16

    Показанное на последней иллюстрации сообщение поначалу ставит в тупик. В каком смысле «not changed»?? Ведь структура указанной базы в новой версии явно изменилась, да еще как! Тут я соглашусь – сообщение составлено явно не удачно и больше путает администратора проводящего модернизацию приложения, нежели помогает ему. А суть этого сообщения такая: после первоначального внедрения приложения MyDAC была создана одноименная база в некотором начальном состоянии и дополнительно приложение было зарегистрировано в системной базе msdb. В последнюю были записаны метаданные зафиксировавшие это самое начальное состояние нашей базы. Понятно, что сразу после инсталляции физическое состояние и структура базы MyDAC соответствует метаданным из msdb на 100%. Но уже в следующую секунду администратор командой из категории DDL-команд (CREATE, ALTER, DROP) может эту синхронизацию нарушить, добавив, скажем, в таблицу базы MyDAC собственную колонку. Так вот изучаемая нами в текущий момент страница провела именно сравнение метаданных в msdb базе и структуры базы MyDAC как она есть в настоящий момент (а вовсе не сравнение двух версий нашего приложения, что кажется логичным) и сообщила, что рассинхронизаций в этом смысле не выявлено. Все верно, мы, как администраторы, никаких изменений в структуре базы и ее объектов не делали, а данные вставляются/редактируются командами из другой группы (группа DML-команд). Они на обсуждаемую синхронизацию не влияют. Заметим, что наличие этой страницы и подобного контроля как бы намекают нам, что будет хорошо если все изменения в структуру базы будут вносится разработчиком, а не администратором. С этим не поспоришь, при таком подходе приложение будет значительно более управляемым а процессы модернизаций будут доставлять меньше головной боли, причем как одному, так и другому.

    Ну а что если все же администратор проявил «самодеятельность» не согласованную с разработчиком? Что будет? Ну понятно что данная страница выведет иное сообщение — The database <имя_базы_данных> has changed и продолжать процесс модернизации, по умолчанию, будет невозможно. Однако, на свой страх и риск, о чем он должен явно заявить выбором опции 'Proceed despite possible loss of changes', администратор может продолжить апгрейд на новую версию. Однако, понятно, что колонка добавленная администратором «в обход» разработчика в новой версии приложения будет потеряна, как, собственно, и все данные в этой колонке содержащиеся.

    Мы, по счастью, мучиться такой дилеммой не должны, а можем просто нажать Next > что переместит нас на страницу 'Summary'. Здесь мы можем посмотреть что мы собираемся сделать и, в частности, убедиться что в данный момент у нас на сервере расположено приложение MyDAC версии 1.1.1.1 а мы готовы провести его апгрейд до версии 2.2.2.2 (рис. 17).


    рис. 17

    Наконец, очередной Next > переместит нас на финальную страницу мастера где начнется физическая модернизация приложения. Мы, как и ранее, можем наблюдать пошаговое развитие «сюжета» этого увлекательного процесса. Он становится еще более увлекательным, когда очередной шаг завершается с ошибкой и мы не можем продолжить модернизацию, рис. 18!


    рис. 18

    Что делать? Ну, во-первых, обратим внимание что некоторые шаги из ранее выполненных были мастером «откачены» (линк 'Rollback success') и иконка этих шагов сменилась с зеленой «галочки» на желтый восклицательный знак. Во-вторых, конечно, следует щелкнуть по ссылке 'Error' в колонке Result с тем, что бы прояснить суть ошибки. Нам будет выведено сообщение как на рис. 19.


    рис. 19

    Из него нам, как администратору, ясно что проблемы возникли при миграции данных (мы поговорим об этом процессе чуть ниже) и попытке вставить их в таблицу 'Product'. Вполне возможно мы не знаем всех замыслов разработчика и название колонки isOnPromotionNow не говорит нам ровным счетом ничего. Поэтому просто копируем сообщение в письмо разработчику, описываем шаги к нему приведшие и просим помощи. Нам же не остается ничего иного, как нажать Finish и завершить работу мастера. Разумеется, нас волнует вопрос как там приложение предыдущей версии (1.1.1.1) себя чувствует? Серьезный ли урон нанесен такой неудачной попыткой модернизацией? Пристальное изучение окна Object Explorer приводит нас к самому утешительному выводу – урона нет никакого! Все 9 объектов входящих в версию 1.1.1.1 на месте, включая и имя входа, и пользователя, и, конечно же, таблицы. Более того, на месте все данные вставленные в эти таблицы с момента ввода этой версии в эксплуатацию! Ну что же, совсем хорошо – можно давать отмашку пользователям на продолжение работы с текущей версией базы и приложения, вся их информация на месте. Нам же остается закрыть Management Studio и ждать ответа разработчика.

    Модернизация Data-tier приложения со стороны разработчика. Исправление ошибок.

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

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

    Из анализа присланного нам текста ошибки (рис. 19) и просмотра текста скрипта Product.table.sql мы понимаем наш промах: для создания новой таблицы скрипт годится вполне, но мы позабыли, что после такого создания строчки имеющиеся в такой же таблице предыдущей версии начнут мигрировать (попросту — копироваться) в таблицу новую, а тут как раз их ждет проблема с упомянутой в тексте ошибке колонкой isOnPromotionNow – что, какое значение, присваивать ей? NULL нельзя, мы запретили, а самостоятельно присвоить какое-то иное значение движок сервера не уполномочен. Решаем что на время миграции можно считать что для всех существующих продуктов никаких акций не проводится, а поэтому в этой колонке должно находиться значение FALSE (0). Переводим это решение в код:

    CREATE
    TABLE Production.Product

    (

    ProductID int IDENTITY(1,1) NOT
    NULL,

    CategoryID int NOT
    NULL,

    ModelNumber nvarchar (50) NULL,

    ModelName nvarchar (50) NULL,

    ProductImage nvarchar (50) NULL,

    UnitCost money NOT
    NULL,

    Description nvarchar (3800) NULL,

    isOnPromotionNow bit DEFAULT(0) NOT
    NULL,


    CONSTRAINT [PK_Products] PRIMARY
    KEY
    NONCLUSTERED (ProductID),


    CONSTRAINT [FK_Prod_Categ] FOREIGN
    KEY (CategoryID) REFERENCES Production.Category

    )

    Что бы отметить исправление столь «значительных» ошибок изменим номер версии – это будет знак администратору что новый пакет содержит дополнительные исправления. Как мы уже делали это в разделе Модернизация Data-tier приложения со стороны разработчика открываем свойства нашего проекта и меняем 2.2.2.2 на, допустим, 2.2.3.4. Сохраняем, перекомпилируем решение, закрываем студию, отсылаем новый пакет MyDAC.dacpac администратору.

    Модернизация Data-tier приложения со стороны администратора. Исправление ошибок.

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

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

    Практически полностью повторяем все шаги раздела Модернизация Data-tier приложения со стороны администратора. На странице 'Select Package' убеждаемся что новый пакет имеет версию 2.2.3.4, а значит, с большой степенью вероятности, ошибка исправлена. Дойдя до финальной страницы мастера подтверждаем это предположение, на этот раз одни зеленые кружочки в отчете о ходе модернизации (рис. 20)


    рис. 20

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


    рис. 21

    Так же заметим, что имя входа (WIN2008\Guest) на сервере осталось, хотя разработчик удалил его из проекта. А, к примеру, пользователь (MyGuest) был удален из новой базы. Все это объясняется теми шагами, что предпринимает мастер в попытке обновить Data-tier приложение. Вот эти шаги (почти все их можно наблюдать в отчете на рис. 20):

    • база данных из нового пакета создается с временным именем (например в нашем случае в этот момент была создана база с именем MyDAC_2_2_3_4__<большое_число>)
    • оригинальная база (она все еще имеет имя MyDAC к этому моменту) переводится в режим «только-чтение»
    • строки данных копируются из таблиц базы MyDAC в аналогичные таблицы MyDAC_2_2_3_4__<большое_число>
    • оригинальная база переименовывается (в нашем случае в MyDAC_1_1_1_1__<большое_число>)
    • новая база переименовывается в имя соответствующее имени модернизируемого приложения (MyDAC)
    • метаданные в базе msdb обновляются так, что бы хранить информацию о структуре новой базы данных

    Генеральная идея здесь заключается в том, что даже если модернизация прошла без проблем (как у нас при второй попытке) новая версия может «не понравиться» администратору/пользователям и будет принято решение отката на версию предыдущую. Сделано все что бы такой откат произошел максимально плавно и без головной боли, но все имеет свою цену, в данном случае:

    • поскольку новая база является именно что «новой» во всех смыслах этого слова данные из старой базы клонируются в двойном объеме. Отсюда не сложно догадаться, что идея проверить свободное место на диске перед началом модернизации будет мыслью очень даже правильной, особенно при апгрейде объемных баз
    • объекты находящиеся вне базы (т.е. уровня сервера, те же имена входов) в принципе нельзя удалять при модернизации – они могут потребоваться при откате на предыдущую версию; более того, как мы увидим далее, имена входов не удаляются даже при полном удалении приложений их создавших!
    • если произошла модернизация, пользователи успели поработать на новой версии, а затем было принято решение об откате на версию предыдущую, то синхронизация данных из новой и старой баз полностью вопрос администратора сервера; правда к этому пункту есть оговорка которая будет разобрана в конце данного раздела

    Таким образом рекомендуется некоторое время после апгрейда поработать на новой версии держа старую «про запас». Когда сомнений в работоспособности первой не останется, вторую можно удалить с, возможно, предварительной ее архивацией.

    Итак, мы получили базу MyDAC c новой структурой, в которой находятся все объекты определенные нами в новой версии и, соответственно, отсутствуют объекты в этой версии удаленные (кроме объектов лежащих за пределами базы, типа имен входов, эти объекты остаются даже если разработчик удалил их из проекта). И, что может еще важнее, в эту новую структуру были перенесены все данные наработанные пользователями в старой версии. Так же немаловажным является то обстоятельство, что в новой технологии возврат к предыдущей версии делается очень легко, можно сказать что план восстановления после неудачных модернизаций прямо встроен в обсуждаемую платформу. Значимость вот такого функционала новой технологии, по скромному мнению автора, переоценить просто не возможно. Даже одним этим фактом Data-Tier Application сразу располагают к себе и вызывают доверие.

    Наконец разберем обещанную выше оговорку связанную с переносом данных из самой последней версии приложения в версию предыдущую, т.е. при откате, если сказать одним словом. Как уже было сказано в целом такая миграция строк данных «в обратном направлении» — забота администратора. Однако в частном случае новый тип приложения может помочь и здесь. Дело в том, что номер версии, при всей своей важности и значимости, чисто технически носит «меточный» функционал, т.е. призван сообщать некоторую информацию разработчику и/или администратору. Сама платформа Data-Tier приложений этот номер совершенно игнорирует. Например, у нас сейчас «активным» является приложение (и база, конечно) версии 2.2.3.4. Но если у нас остался пакет инсталляции (файл MyDAC.dacpac) от версии 1.1.1.1 то нет проблем запустить все тот же мастер модернизации и провести «как бы апгрейд» (на самом деле даун-грейд, downgrade) с версии 2.2.3.4 на версию 1.1.1.1. Поскольку у нас определенно есть требуемый пакет (его можно взять из файлов исходного кода в архиве MyDAC_v_1_1) то описанная задача реализуема, но для экономии места я не стану расписывать ее пошагово. Полагаю, что к этому моменту читатель вполне готов к самостоятельному использованию мастера модернизаций. Так же рекомендую для наглядности эксперимента сначала добавить в таблицы базы текущей версии 1-2 новых строки (эмулируя работу пользователей с этой версией), а потом приступать к понижению версии. Я же приведу лишь снимок экрана снятый с окна Object Explorer после окончания такого «даун-грейда», (рис. 22).


    рис. 22

    Интересно заметить (см. рис. 22), что теперь база MyDAC версии 1.1.1.1 существует в двух «ипостасях» — как база активная (с именем MyDAC) и как база резервная (с именем MyDAC_1_1_1_... и т.д.). И, вполне ожидаемо, появилась еще одна резервная база, той версии с которой мы откатились «вниз». Но что самое важное — и при таком «апгрейде наоборот» мастер действует по тому же самому алгоритму и пытается перенести все данные между таблицами «условно старой» (т.е. 2.2.3.4) и «условно новой» (т.е. 1.1.1.1) версиями баз. Разумеется если такой перенос возможен хотя бы теоретически, т.к. при смене типа колонки с nvarchar (50) на, допустим, bit никакая автоматическая миграция данных невозможна и это понятно. Но, повторюсь, мастер предпринимает все усилия для сохранения максимально возможного объема данных. Так же, практическим выводом из завершающего абзаца данного раздела можно считать настоятельную рекомендацию не торопиться удалять файлы с расширением .dacpac. Чисто технически после успешной инсталляции этот файл не нужен и может быть удален. Однако, как знать, возможно именно эта версия окажется самой удачной для ваших конкретных условий и опробовав версию следующую (а то и несколько следующих) вы захотите к ней вернуться. Тогда пакет который вы уже готовы удалить придется как нельзя кстати.

    Удаление Data-tier приложения с сервера.

    К настоящему моменту мы умеем разрабатывать проекты типа SQL Server Data-Tier Application, умеем инсталлировать их, умеем их модернизировать и преодолевать трудности возникающие в процессе такой модернизации. Что бы полностью «замкнуть» жизненный цикл приложения надо рассмотреть процедуру его корректного удаления с сервера, когда оно становится более не нужным. Тут все достаточно просто, но пару предложений найдется о чем сказать и в этой элементарной процедуре.

    Практика этого раздела подразумевает выполнение всех практик разделов предыдущих.

    Самое главное правило здесь, и я уже упоминал о нем, при отказе от приложения типа Data-Tier следует удалять именно его, а не только поддерживающую базу данных. Допустим, необходимость в MyDAC отпала, его следует удалить. Открываем Management Studio, подключаемся к нужному экземпляру сервера, распахиваем Management->Data-tier Applications, делаем щелчок правой кнопкой мыши по под-узлу с именем приложения (MyDAC) и выбираем 'Delete Data-tier Application...' из контекстного меню (рис. 23).

    рис. 23

    Запускается очередной, уже третий по счету, мастер. На этот раз он поможет нам корректно удалить приложение с сервера. Страницу первую, 'Introduction', традиционно пролистываем – Next >. По сути, весь функционал разбираемого мастера сосредоточен на второй странице – 'Choose Method'. Здесь нам предстоит выбрать один из трех вариантов удаления нашего приложения. Сразу можно заметить что определение нашего Data-tier приложения (иными словами метаданные о нем в системной базе msdb) будут удалены по любому. Разница заключается лишь в том, что будет сделано с поддерживающей базой данных, ее файлами данных и транзакционного лога. Вот эти варианты:

    • Delete registration – ни поддерживающая база, ни ее файлы никак не затрагиваются, база остается полностью работоспособна, она просто не будет ассоциирована ни с каким Data-tier приложением. При необходимости такую ассоциацию можно восстановить (см. след. раздел — Создание Data-Tier Application и DAC модулей непосредственно на сервере)
  • Detach database – файлы базы не затрагиваются, но она сама отключается (detach) от экземпляра сервера. При необходимости, разумеется, можно провести встречную операцию – подсоединения базы (re-attach) и, тем самым, прийти к первому варианту удаления
  • Delete database – тоже что и предыдущий вариант, но еще все файлы базы физически удаляются с диска сервера. Тут, если мы передумаем, нас спасет только полная резервная копия поддерживающей базы данных. Восстановившись из нее мы снова придем к первому варианту удаления
  • Так же интересно заметить что мастер ни при каких условиях не удаляет объекты лежащие вне базы данных (т.е. на уровне сервера), в частности имена входов, о чем есть предупреждение прямо на разбираемой странице мастера (Logins are not removed). Это может быть и хорошо, и плохо в зависимости от обстоятельств, но главное помнить о таком поведении мастера. Велика вероятность того, что мы, как администраторы, захотим после удаления приложения удалить и все созданные им «под себя» имена входов.

    Для нашей практики давайте выберем последний, самый деструктивный вариант удаления — Delete database. Кнопка Next > перенесет нас на очередную малоинтересную страницу 'Summary', и финальный Next > заставит мастер удалить приложение и, возможно, поддерживающую базу выбранным ранее способом. Нажатие на 'Finish' завершит работу мастера.

    Легко убедиться, что после выбранного нами полного удаления у нас нет приложения MyDAC (т.к. нет под-узла с таким именем в Management->Data-tier Applications), нет поддерживающей базы и нет файлов этой базы. Не менее легко заметить, что базы предыдущих версий (с большим числом в имени базы) остаются и мы можем поступать с ними по собственному разумению.

    Вопрос удаления (или нет) созданного нашим приложением имени входа WIN2008\Guest я оставляю на усмотрение читателей, но, понятно, что в общем случае предпочтительно его удалить.

    Создание Data-Tier Application и DAC модулей непосредственно на сервере.

    В ходе изложения данного материала я уже не однократно упоминал, что начало работе с изучаемым типом приложения слоя данных может быть положено с двух сторон: со стороны администратора БД (из SQL Server Management Studio) и со стороны разработчика (из Visual Studio). Инициативы последнего были нами рассмотрены всесторонне, осталось лишь узнать каким образом может проявлять инициативу первый.

    Тут выясняется что инициатива эта может быть двух видов:

    • взять имеющуюся базу и зарегистрировать ее в качестве Data-tier Application без создания выходного DAC-пакета; в этом виде деятельности разработчик не участвует, предполагается что база работает нормально и никаких модификаций ее структуры не планируется. Смысл же создания над рабочей базой управляющего Data-tier приложения – та самая пропущенная в текущей статье функциональность подобных приложений, а именно их мониторинг силами SQL Server Utility. Напомню, что сам мониторинг мы договорились в виду объёмности вопроса не рассматривать, а вот регистрацию существующей базы как один из этапов подготовки к такому мониторингу мы посмотрим в этом разделе
    • взять имеющуюся базу и извлечь (extract) из нее DAC-пакет содержащий определение этой базы. Такой пакет будет содержать все скрипты по созданию объектов базы и плюс скрипты по созданию связанных объектов уровня сервера. Типично пакет содержит скрипты создающие все таблицы базы, все хранимые процедуры, представления, всех пользователей, а также скрипты создания имен входов которые отображаются в этих пользователей базы. Тут уже разработчик играет центральную роль, т.к. извлеченный пакет будет передан ему для дальнейшей модификации/модернизации в привычной разработчику Visual Studio 2010. Эту активность администратора мы так же посмотрим в этом разделе.

    Отмечу что обе активности краткое описание которых было приведено только что полностью независимы. Иными словами регистрация Data-tier Application не извлекает DAC-пакет и наоборот. Так что если мы хотим и зарегистрировать, и извлечь – выполняем эту задачу в два «захода».

    Практика этого раздела не требует выполнения каких либо практик раздела предыдущих. Вместе с тем, если предыдущие практики были сделаны, удостоверьтесь что вы удалили тестовое Data-tier приложение способом описанным в разделе Удаление Data-tier приложения с сервера. Так же удалите все резервные базы этого приложения (имена таких баз обычно содержат номер версии, цифры которого разделены не точками, а подчерками). Желательно что бы узел Management->Data-tier Applications окна Object Explorer не содержал никаких зарегистрированных Data-tier приложений.

    Для этого раздела экспериментальной станет база AdventureWorksDW2008R2. Инсталляционный пакет устанавливающий учебные базы (в т.ч. базу AdventureWorksDW2008R2) нового выпуска MS SQL Server можно взять здесь: http://msftdbprodsamples.codeplex.com/releases/view/45907. Обратите внимание, что нам нужна именно DW (Data Warehouse) база данных. Обычно она используется в электронной документации по SQL Server для демонстрации функций бизнес-аналитики, но в рамках данного раздела мы смотрим на нее как на обычную базу содержащую ряд объектов – таблицы, представления, триггеры и т.п.

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

    Итак, исходим из того что в данный момент наш сервер не содержит никаких зарегистрированных Data-tier приложений, что у нас есть база данных AdventureWorksDW2008R2 и что мы способны в любой момент времени восстановить ее. Держа все это в голове приступаем к первой активности – регистрации нового Data-tier Application из имеющейся базы данных.

    Для этого находим в окне Object Explorer необходимую базу и из ее контекстного меню вызываем по пути Tasks->Register as Data-tier Application... мастер регистрации нового приложения (рис. 24).

    рис. 24

    На странице 'Introduction' запустившегося мастера традиционно щелкаем Next > и попадаем на страницу 'Set Properties'. На ней можно:

    • изменить имя, под которым приложение будет зарегистрировано. По умолчанию имя совпадает с именем исходной базы данных, что, судя по всему, является оптимальным вариантом в 99% случаев
    • изменить номер версии. Вообще не актуально если только не предполагается модернизация приложения
    • дать краткое описание регистрируемому приложению, обычно описывающему его назначение. Может быть позже просмотрено из узла 'Data-tier Applications node' в Management Studio

    Пожалуй что нас устраивают все значения по умолчанию, снова Next > и страница 'Validation and Summary', пожалуй что центральная во всем мастере. Именно на ней все объекты регистрируемой базы делятся на 2 группы: поддерживаемые Data-tier приложением и не поддерживаемые им. Помните наше Введение и разговор о плюсах/минусах трех типов проектов в Visual Studio? Там мы отметили самый главный, пожалуй, недостаток нового типа проекта – НЕ 100% поддержку объектов (более точно – типов объектов) мира SQL Server-а. Как легко видеть из рис. 25 этот самый недостаток в нашем случае встал «в полный рост», из 45-ти объектов целевой базы 44 поддерживается, а 1 нет. Распахнув узел 'Objects not supported in a DAC' мы узнаем что злосчастным «камнем преткновения» стал триггер DDL типа. Напомню, что убедиться в абсолютной справедливости вывода мастера и еще раз просмотреть типы поддерживаемых объектов можно в статье MSDN «Features Supported in Data-tier Applications» (текущий ее адрес http://msdn.microsoft.com/en-us/library/ee362013.aspx). Легко видеть, что DML триггеры в таблице этой статьи упоминаются, а DDL как раз и нет.


    рис. 25

    Ну что ж, из «продуктивных» кнопок нам остался доступен на текущий момент лишь 'Cancel', его и щелкаем. Теперь у нас есть все основания хорошенько подумать – что делать дальше. Вполне возможно, что следует отказаться от идеи регистрации по крайней мере до выхода второй версии рассматриваемой технологии. В ней, как мы все надеемся, список поддерживаемых типов объектов если и не станет всеобъемлющим (чего хотелось бы), то будет хотя бы значительно расширен. Но, допустим, регистрация базы в качестве приложения нужна нам настолько, что мы готовы даже пойти на изменение ее структуры. В нашем учебном примере мы применим подход самый «драконовский» — просто удалим «неудобный» объект без всякого анализа последствий такого шага. Конечно, не пытайтесь повторить такой «финт» на рабочих базах, сначала внимательно исследуйте зависимости остающихся объектов от объекта удаляемого!

    Итак – удаляем: распахиваем в Object Explorer Databases->AdventureWorksDW2008R2->Programmability->Database Triggers, RMB по единственному триггеру ddlDatabaseTriggerLog и выбираем 'Delete' из контекстного меню. OK, и триггер убран. Перезапускаем мастер регистрации и прощелкиваем Next > до проблемной страницы 'Validation and Summary', где на этот раз видим что все 44 оставшихся объектов нашей базы поддерживаются DAC приложением! Наконец-то! Очередной Next > регистрирует нашу базу и заносит ее метаданные в базу msdb, а 'Finish' завершает работу мастера. Распахнув теперь узел Management->Data-tier Applications окна Object Explorer убеждаемся что новое приложение действительно создано (рис. 26). С ним, потенциально, можно проводить 2 основных операции рассмотренных нами ранее (модернизация/удаление) и, что в данном случае важнее, можно осуществлять мониторинг этого приложения.


    рис. 26

    Переходим к активности номер 2 — извлечению из все той же базы AdventureWorksDW2008R2 DAC-пакета с целью предоставить разработчику «стартовую площадку» по модификации структуры существующей базы. Начинаем очень похоже с предыдущей активностью, только пункт контекстного меню на этот раз называется Extract Data-tier Application... (рис. 27).


    рис. 27

    И мастер запускаемый этим пунктом тоже весьма схож с предыдущим. На его странице 'Introduction' щелкаем Next > и попадаем на страницу 'Set Properties', на которой по сравнению с мастером предыдущим добавилось одно поле – 'Save to DAC package file'. В нем мы указываем полный путь к выходному .dacpac-пакету, а так же имя этого пакета. Оставьте значение по умолчанию или введите удобный для вас путь. Три оставшихся поля трогать не будем, щелкаем Next >. Снова знакомая по предыдущему мастеру страница 'Validation and Summary'. И смысл ее такой же – разделить все объекты целевой базы на поддерживаемые DAC-приложением и не поддерживаемые. После предыдущей активности у нас все оставшиеся 44 объекта поддерживаются, можем щелкать на очередной Next > перемещаясь тем самым на финальную страницу где происходит непосредственно генерация выходного пакета. 'Finish', как всегда, завершает работу мастера.

    Все! Можно закрыть Management Studio и в любом файловом менеджере найти выходной DAC-пакет по указанному нами на странице мастера 'Set Properties' пути. Если хотите – распакуйте выходной .dacpac-файл и ознакомьтесь с его содержимым. После чего «отправьте» его электронной почтой разработчику. И, да — не забудьте восстановить базу AdventureWorksDW2008R2 из вашего резервного источника!

    Импорт Data-Tier приложения в проект Visual Studio 2010.

    Наконец в заключительном разделе статьи мы посмотрим что будет делать разработчик получивший от администратора баз данных DAC-пакет извлеченный из существующей БД. Итак, мы снова разработчики и только что получили по почте письмо с вложенным файлом AdventureWorksDW2008R2.dacpac.

    Если вы пропустили практические шаги предыдущего раздела, но хотели бы выполнить практику раздела текущего воспользуйтесь файлом AdventureWorksDW2008R2.dacpac. из архива AdventureWorksDW2008R2. Иначе предпочтительно просто продолжить работу с вашим собственным сгенерированным пакетом.

    Разумеется, первым делом открываем наш основной инструмент — Visual Studio 2010, и начинаем новый проект типа SQL Server Data-Tier Application, совершенно так же, как это происходило в начале раздела Создание DAC модуля в Visual Studio. Только на этот раз назовите проект по имени пакета который мы собираемся в проект импортировать — AdventureWorksDW2008R2. Когда проект появится в окне Solution Explorer щелкните правой кнопкой мыши по имени проекта и выберите в контекстном меню пункт 'Import Data-tier Application...' (рис. 28).


    рис. 28

    Это приведет к запуску очередного мастера, на этот раз помогающего импортировать Data-Tier Application. На вводной странице традиционно щелкаем Next >. На странице 'Specify Import Options' у нас 2 выбора:

    • если мы располагаем прямым подключением к серверу на котором расположена целевая база, то мы можем извлечь Data-Tier Application прямо из нее, никакие .dacpac-файлы от администратора нам не нужны
    • если прямого подключения нет, то мы должны указать как раз такой .dacpac-файл

    Мы разыгрываем второй сценарий, а потому выбираем опцию 'Import from a data-tier application package' и с помощью кнопки 'Browse' указываем расположение файла AdventureWorksDW2008R2.dacpac. Если бы импортируемый пакет содержал еще политику отбора серверов мы, опционально, могли бы импортировать и ее в наш проект. В данном случае AdventureWorksDW2008R2.dacpac никакой политики не содержит и отмечать опцию 'Import server selection policy' смысла по любому нет. Щелкаем Next >. Переходим на заключительную страницу мастера где и происходит непосредственный импорт объектов целевой базы. Нам выдается краткий отчет о проделанных действиях. 'Finish', как всегда, завершает работу мастера.

    Теперь переключившись в окно Schema View и распахивая различные узлы дерева в этом окне мы можем убедиться что все 44 объекта целевой базы находятся в нашем проекте в виде скриптов эти объекты создающие (рис. 29).


    рис. 29

    Если бы в течении только что описанной процедуры мастер обнаружил бы во входном пакете определение объекта базы которое он бы не смог распознать, то скрипт по созданию такого объекта был бы помещен в специальный файл ScriptsIgnoredOnImport.sql. Быстрей всего доступ к этому файлу можно получить из окна Solution Explorer, т.к. в нем он является под-узлом узла 'Scripts'. Легко убедиться что в нашем случае этот файл пуст (хотя и существует) – значит никаких проблем при импорте не возникло.

    Теперь мы можем приступать к модификации/дополнению структуры базы AdventureWorksDW2008R2 точно так же как мы это делали ранее с базой MyDAC и в целом можно было бы завершать данный раздел, а вместе с ним и статью. Но давайте задержимся еще на 5 минут. Дело в том, что Visual Studio 2010 предлагает разработчику очень интересный инструмент сравнения структур двух баз данных. К сожалению, многими разработчиками этот инструмент недооценен, а начинающие вполне даже могут не подозревать о нем. Хотелось бы, пользуясь случаем и статьей очень близкой тематики, закрыть этот пробел и показать хотя бы самое примитивное использование этого инструмента.

    Давайте начнем с того, что добавим нашему проекту первую (поскольку пока у него нет ни одной) хранимую процедуру. Как добавлять объекты с помощью окна Schema View мы уже знаем, назовем нашу первую процедуру GetVersion. Изменим скрипт ее создания на вот такой:

    CREATE
    PROCEDURE [dbo].[GetVersion]

    AS
    SELECT @@VERSION

    С помощью того же окна удалим из нашего проекта все имена входов (logins). В моем случае проект содержал единственное такое имя — WIN2008\Administrator. Удаляем его и все прочие имена входов (если они есть). Сохраним все изменения (File->Save All) и перекомпилируем проект (Build->Rebuild Solution). Теперь представим что число добавленных/измененных/удаленных объектов исчисляется не единицами (конкретно 2-мя в нашем случае), а десятками и сотнями. Вполне уместен в этом случае вопрос «а что именно и как изменилось в проекте сейчас по сравнению со стартовой точкой». Знание этого аспекта разработки может потребоваться как разработчику, так и администратору в зависимости от текущей стадии жизненного цикла проекта. Visual Studio 2010 предлагает простой и наглядный инструмент для ответа на этот вопрос, тот самый ради которого я решил еще немного задержать ваше внимание — Schema Comparison. Вызовем этот инструмент из главного меню: Data->Schema Compare->New Schema Comparison... . Инструмент оформлен в виде двух панельного окна (рис. 30).


    рис. 30

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

    • проект типа data-tier application project/database project из текущего решения
    • реальная база данных расположенная на MS SQL Server-е с которым мы способны установить подключение из студии
    • локальный файл базы данных, только подразумевается под этим отнюдь не .mdf-файлы (что казалось бы логичным), а файлы двух расширений: .dbschema и .dacpac. Первый получается как результат компиляции проекта типа database project, а как получается второй все читатели, несомненно, и сами теперь знают. Вот определение структуры записанное в одном из таких файлов и может выступить в качестве одной (а то и обоих) сторон сравнения схем

    Что бы опробовать этот инструмент оставим для «исходной» схемы наш текущий и слегка модифицированный проект (он и выбран по умолчанию), а для «целевой» схемы укажем файл с которого началась работа в текущем разделе, AdventureWorksDW2008R2.dacpac.

    Рекомендую самостоятельно изучить возможности кнопки 'Options...' рассматриваемого инструмента. Вкратце, она позволяет задать какие именно объекты обоих схем будут сравниваться, как именно, какие типы различий можно игнорировать и что будет записано в выходной скрипт содержащий команды синхронизации обеих схем.

    Формат статьи не дает возможности разобрать все возможности скрывающиеся за кнопкой 'Options...' и мы просто для пробы выставим опцию говорящую о том, что не следует детектировать различные настройки опции ANSI_NULLS в «исходной» и «целевой» схемах (что, кстати, имеет место в нашем случае). Делается этот шаг так, как показано на рис. 31.


    рис. 31

    Нажатие OK возвращает нас к основному двух панельному окну, а еще один OK запускает сравнение. Ясно, что в нашем случае подавляющее большинство объектов в обеих схемах будет совпадать и для них в колонке 'Status' итогового отчета будет стоять Equal. Отфильтруем отчет так что бы он содержал только изменившиеся объекты. Для этого на инструментальной панели нажмем кнопку с воронкой (он же фильтр, самая левая на панели) и выберем из выпадающего списка 2 пункта: Missing Objects и New Objects (рис. 32).


    рис. 32

    Теперь ясно видно, что в «исходной» схеме появился один объект (хранимая процедура) и один объект был из нее удален (имя входа), рис. 33.


    рис. 33

    В колонке 'Update Action' приводится то действие которое надлежит выполнить дабы «целевая» (правая в окне) схема стала эквивалентна «исходной» (левой). А помимо этого в нижней части окна изображенного на рис. 33 приводятся скрипты которыми каждый объект (не важно новый или пропущенный) был создан в левой или правой схемах. Щелчком на конкретном объекте в таблице сопоставления мы эти скрипты можем просмотреть.

    Так же, заметьте, что настройки сравнения (а именно – какие объекты и сущности выступают в роли «исходной» и «целевой» схем, а так же все опции скрываемые кнопкой 'Options...') можно сохранять в .scmp-файл. Удобнее всего это делать из окна Solution Explorer, щелкнув правой кнопкой по узлу 'Schema Comparisons' и выбрав из контекстного меню 'Add'->'Schema Comparison...', рис. 34.


    рис. 34

    Затем нам будет предложено ввести имя нового «сравнителя схем» и после щелчка по 'Add' будет представлено знакомое двух-панельное окно с рис. 30. Настраиваем его, проводим сравнение, анализируем результаты, а перед тем как закрыть итоговое окно отчета вызываем File->Save <schema_comparison_name>. Настройки сравнения сохраняются под указанным именем в узле 'Schema Comparisons' нашего проекта. Двойной щелчок по этому файлу в будущем будет открывать «заполненное» окно сравнения двух схем и нам останется лишь нажимать 'OK' для непосредственного запуска сравнения. Очень удобно, если мы в конце каждого рабочего дня (а может быть часа) задаем себе вопрос – насколько мы теперь далеко от исходной схемы? Вот такое «сохраненное сравнение» за несколько секунд даст нам наглядный ответ.

    Полагаю, что уверенное владение столь замечательным инструментом должно стать обязательной чертой любого профессионального разработчика баз данных! И не забывайте – мы посмотрели лишь самый примитивный вариант применения Schema Comparison, реальные его возможности много богаче. Призываю вас продолжить изучение этого инструментария самостоятельно, и в качестве «стартовой площадки» такого изучения предлагаю вашему вниманию очень добротную статью из MSDN «Compare and Synchronize Database Schemas» (текущий адрес http://msdn.microsoft.com/en-us/library/dd193250.aspx). В ней, помимо прочего, можно найти ссылки на несколько толковых «Как сделать…» (How to...) и «Пошаговых практик» (Walkthrough) наглядно демонстрирующих различные аспекты работы с Schema Comparison.

    Заключение.

    Итак, уважаемые читатели, мы с вами настолько подробно насколько это допустимо в рамках отдельной статьи разобрали одну из новых технологий появившихся в последнем выпуске SQL Server 2008 R2, а именно Data-tier Application. Его «боевой» и базовой единицей является пакет распространения, т.е. файл с расширением .dacpac. Важно понимать, что .dacpac-файл может быть использован для двух целей: для осуществления первоначальной инсталляции нового Data-Tier Application И для апдейта уже существующего Data-Tier Application. Не смотря на свою «молодость» новая технология предлагает продуманный и взвешенный подход ко всем фазам разработки приложений баз данных. Имеется удобный инструментарий для создания таких приложений «с нуля» или на основе имеющейся базы. Сделано все, что бы готовое приложение инсталлировалось максимально гладко и не требовало от администратора, такую инсталляцию выполняющего, глубоких (и даже поверхностных) знаний о составе и структуре инсталлируемого приложения. В тоже время состав установочного пакета полностью открыт и администратор имеет все возможности изучить его настолько подробно, насколько пожелает прежде чем принять решение о запуске инсталляции. Крайне скрупулёзно и тщательно решен вопрос апгрейда (причем как «вверх», так и «вниз») ранее инсталлированного приложения к предыдущей/следующей версии. И, самое главное, наконец-то разработчик и администратор действительно вместе «строят» итоговое решение, а не занимаются разграничением «зон ответственности». Мы так же отметили и недостатки, без которых, наверное, ни одна технология не получила бы широкого распространения. Трудно ожидать что бы прямо со старта нам предоставили идеальный инструмент без единой шероховатости. Так и здесь – шероховатости (и еще какие!) имеют место быть, и, основная проблема – не полная поддержка всех возможных объектов мира MS SQL Server. Тем не менее рассмотренная нами новая особенность сервера (а так же дополняющий ее новый тип проекта в Visual Studio) выглядит крайне многообещающе и мы вправе ожидать исправления основных ее недочетов в ближайших версиях MS SQL Server. В целом, мое личное мнение сложившееся после написания нескольких тестовых проектов с привлечением новой технологии и одного проекта реального (правда крайне скромного в смысле масштабности), а так же текста и примеров данной статьи: Data-tier Application вполне готовы к промышленной эксплуатации прямо сейчас для простых и средне-простых проектов баз данных. «Тяжелые» и сложные решения нашему «новобранцу» будут пока, пожалуй, не по плечу. Тут придется задействовать «тяжелую артиллерию»: существующие уже несколько выпусков Visual Studio проекты баз данных и сервера.

    Вне поля нашего внимания остались множество других новшеств SQL Server 2008 R2, причем одно из них — SQL Server Utility — имеет самое непосредственное отношение к рассмотренным нами Data-tier приложениям. Но, как уже упоминал автор, он надеется рассмотреть эту утилиту в отдельной статье, в которой так же постарается ответить на вопросы по статье текущей, если таковые возникнут.

    Благодарю всех своих читателей за внимание и надеюсь на новую встречу.

    Щербунов Нейл Анатольевич

    net4net@gmail.com

Комментарии

  1. Интересно, кто-нибудь прочитал до конца? В тексте есть указание на бонус за прочтение 😉

  2. О, как раз то, что надо. Увлекательное чтиво на утро себе обеспечил )

  3. Плохо, что нет версии для печати.

  4. Статья изначально оформлена как doc-файл, так что отсутсвие возможности распечатки исключительно промах движка на котором сайт построен. А так, возможность печати столь «массивных» текстов — безусловный must have, тяжко с экрана столько информации воспринимать, тут и спорить не о чем.

  5. Прочитал Вашу статью, очень понравилась, заставила посмотреть по иному на разработку БД, особенно сейчас, т.к. идет новый проект на SQL Server 2008 R2, и есть возможность использовать новые технологии в ее реализации. Очень порадовала возможность создания DACL из существующей БД.

    Спасибо за статью, буду ждать обзор по SQL Server Utility

  6. В догонку, на текущем проекте не удалось опробывть из-за использования CLR. (hierarchyid)...жаль, но остается надеятся на СП1, что в нем уже будет расширена поддержка типов SQL Server. А пока по старинке, для текущего проекта

  7. >>Прочитал Вашу статью, очень понравилась

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

    >>Спасибо за статью, буду ждать обзор по SQL Server Utility

    Тоже рассчитываю на вторую статью, тем более разрозненные ее куски уже написаны. Но по ней работы еще много...

    >>что в нем уже будет расширена поддержка типов SQL Server

    Безусловно это главный «disadvantage» новой технологии — не полная поддержка типов объектов, о чем в статье и говорил. Ждем ее развития.

  8. Антон, (3.)!

    Версия для печати появилась

  9. Отличная статья. Хотелось уточнить — какая редакция Visual Studio и SQL Server необходима для создания решения для Data-Tier Application со стороны разработчика?

  10. >>Отличная статья

    Спасибо, приятно. 🙂

    >>какая редакция Visual Studio и SQL Server необходима для создания решения

    Сам интересовался этим вопросом, и в части SQL -я имею 100%-й ответ, а в части Студии — ответ только предположительный, но весьма обоснованный.

    Стало быть — SQL Server: msdn.microsoft.com/en-us/...ry/ee240739.aspx, статья «Understanding Data-tier Applications». Раздел «Data-tier Application Support by the Versions of SQL Server» приводит вменяемую табличку поддержки DAC-а разными ВЕРСИЯМИ сервера. А подпись под табличкой говорит о том, что информация о версии относится ко всем РЕДАКЦИЯМ этой версии. Тут все кристально ясно — все редакции равны в части DAC.

    Студия 2010: Как следует отсюда www.microsoft.com/visuals...cts#compareTable Database Development как таковой полноценно реализован только в Премиуме и в Ультимейте. Думаю не будет сильной ошибкой предположить что это каксается и DAC-а, т.к. последний есть именно что инструмент девелопинга баз данных.

  11. Супер! Большое спасибо за статью!

    ЗЫ «Я не робот» очень порадовало, возьму капчу на заметку))

  12. Очень подробная и отличная статья

Опубликовать

Я не робот.