|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
ptr128 msLex Выше же я говорил, что мы так не делаем, а пользуемся deploy. Неразрешимых проблем у нас при этом не возникало. Вот и расскажите всем, как надо было решать проблему, когда deploy SSDT 2016 глухо виснет при наличии хотя бы одного GRANT EXECUTE ANY EXTERNAL SCRIPT в целевой БД. Если никакие настройки деплоя не помогают (ignore permissions и т.п.), не использовать эту фичу до появлении поддержки на стороне SSDT. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2020, 17:27 |
|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
msLex не использовать эту фичу до появлении поддержки на стороне SSDT. А если это требование бизнеса, которому R Service жизненно необходим? Разрывать контракт и платить неустойку? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2020, 17:37 |
|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
ptr128, Это случаем не тот баг для которого можно было сначала явный revoke в качестве workaround сделать? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2020, 17:56 |
|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
ptr128 Разрывать контракт и платить неустойку? Оценивать возможность выполнения контракта до а не после подписания не предлагать? PS Переход на новую версию SQL Server сразу после ее релиза так себе затея. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2020, 18:01 |
|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
env, он самый. Но такой workaround применим был только если это можно было сделать по бизнес процессу. Когда клиент на R Service гоняет модели, выполнящиеся десятки часов и в любой произвольный момент хотя бы одна такая модель считается, за REVOKE могут и по башке настучать. Больно... msLex, да не оцените Вы все. Не реально это. К тому моменту 2016 сервер только вышел. Еще preview. Клиент R Service гонял на нем месяц от силы, очень обрадовавшись такой возможности. MS же в know issues эту проблему вообще включил только через несколько месяцев после начала проекта. Не было никакого перехода. Был новый проект с использованием R Service. И окончательно в продуктив он попал уже на 2017-ом SQL Server через два года. Но это уже совсем другая история... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2020, 18:07 |
|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
= I.= Насчёт порядка обработки скриптов. Это действительно важная вещь. Внутри директории для файлов по умолчанию действует алфавитный порядок следования (для обработки на сервере). То, что надлежит поместить в начало трансляции — следует включить (имена файлов SQL) в файл $sql_order.list . Например: ;SQL-TRANSLATION PRIMARY ORDER: ++ [Categories].sql ++ [Genres].sql ++ [Authors].sql ++ [Publishers].sql ++ [Series].sql Те SQL-файлы, чьи имена начинаются с точки, обязаны присутствовать в $sql_order.list , например: ;SQL-TRANSLATION PRIMARY ORDER: .ToRomanNumber.Ext.sql .ToRomanNumber.sql Существует разная мощность группы трансляции: 1) Отдельный SQL-скрипт (конкретный файл); 2) Простая подгруппа SQL (обычно это все SQL-файлы каталога); 3) Множество подкаталогов внутри текущего каталога (один уровень), плюс все файлы *.sql (так называемая большая группа). В SQL-файл принято группировать файлы в виде подмножеств, размещая их в подкаталогах (уровня вложенности =1), давая подпапкам групп алфавитно упорядоченные имена (что достигается за счёт применения цифрового номера). Например: 00 error_gen initials 01 drop_object 02 drop_objects Или же: Procedures_00 Procedures_01 Утилита $SQLTRANS обрабатывает (исполняет на сервере) композитный скрипт за один приём. Для осуществления же обработки в несколько стадий (трансляции) используются возможности последовательного вызова нескольких трансляций SQL — посредством сценария CMD. = II.= Помимо собственно скриптов с SQL, важнейшей составляющей являются импортные файлы свойств: $sql_settings.cmd , $….cmd , @….cmd , а также $sql_settings.sql (как альтернативный вариант). В файлах свойств принято держать общедоступные макроконстанты (выражаемые друг через друга определения: “ set …=… ”). Это в какой-то степени подобно тому, как работают заголовочные H-файлы языка C (только намного проще). Кстати, в файлах @….cmd принято временно включать поддержку UTF-8 (кодовая страница 65001), на этапе присваивания свойств. Все же SQL-скрипты — естественно в UTF-8. = III.= SQL-файл — это не только набор скриптов. Для подготовки комплексной трансляции работает подпрограмма SqlCatPP.exe , которая, помимо упорядоченной конкатенации SQL-файлов, производит, также, лёгкий предварительный (до SQLCMD) препроцессинг скриптов, с целью исправления номера строки, если применялась команда :SetVar (по-умолчанию такая строка выпадает из результатов SQLCMD, сбивая тем самым номер исходных строк на единицу). SqlCatPP же при встрече в файле :SetVar (pascal-style) добавит в скрипт закомментаренную строку ( // :SetVar … ), т. е. номер строки возможной ниже ошибки будет корректным. $SQLTRANS реализована не монолитно, а в виде CMD+EXE. Привязка же к к SQLCMD сохранена по причине множества поддерживаемых ею SQLCMD-режимов и параметров, которые можно передать в неё, используя переменную $sqltrans.AdditionalParams . Например, простейшая команда-сценарий generate_guid_list.cmd : @echo off setlocal set $sqltrans.AdditionalParams=-y0 $SqlTrans "%~n0.sql" "guid_list.txt" goto ERROR :ERROR echo ∙ pause EXIT 255 “ -y0 ” (для SQLCMD) здесь использовано для исключения заголовков колонок из текста результатов (т. е. выводятся лишь сами данные). Кроме того, $SQLTRANS (её командная часть) легко доступна для исправления в соответствии с эксклюзивными пользовательскими нуждами. Прочие же её составляющие подпрограммы-компоненты-зависимости ( SqlCatPP.exe , ConfirmationPause.exe , TypeInColor.exe ), а также другие утилиты SQL ( $sqlupload.cmd , SqlToCsvExport.exe , $sql.cmd , $sqlcon.cmd ) — тоже доступны для исправления. Имеются, также, исходники к простейшему FAR-плагину CmdCpAuto.dll , как и вспомогательные макросы FAR: Editor_CtrlAltEnter.lua , Editor_CtrlF12.lua , Editor_CtrlR.lua (см. каталог: “HandicraftSDK\CMD-utilities\Shell\Integration”, файлы *.lua , *.txt ). Всё работает в комплексе, а также может быть скорректировано при желании. = IV.= Технология SQL-файл пригодна для 2-х основных целей: 1) Хозяйственная правка базы данных; выполнение действий/операций в режиме ручного управления (с правами администратора SQL-сервера); произведение теста операций (с откатом транзакции), и т. п. 2) Программирование активной части приложения БД на языке T-SQL (так называемые программатики ), представляющей из себя набор процедур, функций и подобное. Для программирования в БД — возможно (опционально) задействование Усиленного Transact-SQL , в виде макроопределений и хелперов библиотеки SQLAUX (подключается к трансляции в главном файле настроек SQL-проекта $sql_settings.cmd ). ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2020, 22:53 |
|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
Хорошо, что кто-то делает что-то новое. Плохо, что это новое никому не нужно, т.к. не превосходит старое ) Чем ваш проект лучше стандартной связки SSDT + TFS/GIT? Зачем разработчику изучать ваше ПО, если есть стандартное? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2020, 23:09 |
|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
Критик Чем ваш проект лучше стандартной связки SSDT + TFS/GIT? "Чукча не читатель, чукча писатель?" (c) 1. Тем, что SSDT обеспечивает поддержку новых версий MS SQL Server с существенной задержкой (до года). Что иногда приводит к полной невозможности его использования (история с GRANT EXECUTE ANY EXTERNAL SCRIPT). А такой проект легко адаптируется к любой версии MS SQL Server. 2. SSDT очень неудобно использовать в гетерогенных средах. Например, проект для MS SQL + PostgreSQL. 3. SSDT совершенно не поддерживает никаких макроопределений, ограничиваясь только средствами SQLCMD. Сюда прикрутить любой препроцессор сложностей не составит. Например, попробуйте из SSDT публиковать проект в разные схемы одной и той же БД в зависимости от конфигурации проекта. Только без переноса всего проекта в PostDeployment, как предлагал выше msLex. Вот если бы RedGate был бесплатен, я бы сам сказал, что подобный проект не нужен. P.S. Заставил себя промолчать про TFS... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2020, 23:41 |
|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
ptr128 msLex, я в курсе, что можно использовать множество файлов. А вот утверждая, что можно обойтись только массовой заменой CREATE, Вы глубоко заблуждаетесь. Потому что метаданные могут меняться. Причем могут не только добавляться поля таблицы, но так же меняться CONSTRAINT-ы, что для предлагаемого Вами подхода вообще печально. После чего Вы становитесь вынужденными или руками прописывать все эти IF ... DROP/ALTER/CREATE, или все же взвоете и станете использовать подсистему сборки отличную от SSDT, в которой подобные процессы более-менее автоматизированы. Что будет логичным, так как толку от SSDT, когда весь код деплоится через PostDeployment - НИКАКОГО. Берете в зубы Atom и радуетесь после убогого VS ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2020, 00:41 |
|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
Сергей Китаев, редактировать SQL файлы на корпоративном уровне? Это даже не знаю, сколько вызовет проблем, не говоря о средствах управления проектом и тестировании. Студия прекрасно справляется и с управлением, и с разработкой, и с версионированием и, главное, с публикацией проекта. Студия также позволяет выполнять развертывание CLR процедур, решение объединяет ВЕСЬ выпускаемый продукт - Reporting, Integration, клиентское приложение, утилиты, WEB проект и тому подобное. Интеграция позволяет легко контролировать код и версионировать ВЕСЬ выпускаемый продукт. Полностью контролировать поставку всех, подчеркну, разнородных компонентов продукта, а не выполнять узкий контроль только SQL файлов. Далее, инструменты публикации и сравнения, IntelliSense, отладка в одном рабочем месте, интеграция с TFS. На фоне этого процесс разработки в текстовом редакторе выглядит крайне бледно. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2020, 10:21 |
|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
Владислав Колосов, Вам сколько за рекламу MS платит? "прекрасно справляется" - только подождать надо годик, пока он станет поддерживать уже выпущенную очередную версию MS SQL. "решение объединяет ВЕСЬ выпускаемый продукт" - покажите мне, как в VS опубликовать гетерогенный проект, включающий в себя кроме MS SQL еще и PostgreSQL, кастомизированный Redmine (Ruby on Rails) вместе c MySQL и пачку утилит на Linux. А если к этому добавляется еще кросскомпиляция и прошивка удаленных микроконтроллеров, то с VS можно сразу вешаться. "интеграция с TFS" - Вы попробовали вести проект серийного продукта в TFS, когда нужно поддерживать несколько версий продукта, да еще и с кастомизациями для разных клиентов? Да я скорее древним SVN буду пользоваться в таком случае, чем TFS. "редактировать SQL файлы на корпоративном уровне" - расскажите, пожалуйста, как можно вести разработку SQL НЕ РЕДАКТИРУЯ SQL файлы? К тому же речь идет о SQL проекте. Вы уж простите, но я даже не представляю, как можно писать код хранимых процедур в VS. В DBEaver - легко. В SSMS - вполне возможно. Но в VS? Увольте... Публикация в VS вообще никакая. Попробуйте подставить в публикуемый SSRS отчет разные логотипы (embeded image) в зависимости от конфигурации публикации. Попробуйте публиковать SSDT SQL проект в разные схемы одной БД в зависимости от конфигурации. Для публикации серьезного корпоративного продукта есть RedGate. Для сторонников OpenSource - liquibase. Допустим самописный toolchain. Но уж точно не SSDT. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2020, 11:07 |
|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
Два занятных вопроса = I.= Подавляющее количество примеров с SQL, включая фирменную документацию, использует для инструкций стиль с заглавными буквами, подобно юридической секции DISCLAIMER. Сущностные же имена (как большие так и маленькие) при этом проглядывают не столь отчётливо, если сравнивать с классическими языками. (Попробуйте всё писать в стиле отказа от обязательств; даже не программу, а просто сколько-нибудь объёмный текст.) Мне думается, что подобная странная манера выработалась в связи с тем, что исторически SQL присутствовал в основном лишь в виде вкраплений в программы на других языках, а посему следовало выделять подобные фрагменты (используя верхний регистр). У SQL-кода вообще тяжеловато с пропиской; отношение к нему в этом смысле намного хуже, нежели к классическому языку программирования, где предусмотрены все средства хранения. Тут ещё и устройство самого SQL-сервера диктует свои правила, а там всё весьма консервативно; SQL-файлы с запросами просто так на сервер не выложишь (подобно JS/HTML), необходимо генерировать объекты. = II.= Что Вы думаете по поводу контроля за выполнением инструкций в языке T-SQL, касательно надёжности их исполнения в режиме по умолчанию, т. е. при отсутствии try-catch обёртки? В подобном старомодном режиме необходимо проверять почти каждую инструкцию на успешность её исполнения, анализируя переменную @@error . (Существуют, конечно, xact_abort и arithabort . Возможно, также, использовать ловлю исключения.) Данный режим (управление инструкциями) в качестве умолчания, на мой взгляд годится, разве что, где-нибудь в системном коде драйвера (в режиме ядра), но никак не в языке с высоким уровнем обращения к данным, в смысле обработки транзакций. Т.е., для выполнения, собственно, инструкций — также необходима достойная чёткость (в режиме по умолчанию). В SQL-файл принято оборачивать весь скрипт (или тело Х.П.) в обрамляющие $(BEGIN_AUX) и $(END_AUX) , на самом верхнем уровне. Препроцессор же SQLCMD раскрывает эти макрослова (при компиляции) в соответствующие последовательности, предназначенные для перехвата возможного исключения (с повторным выбрасыванием ошибки). Пример того, как выглядит сохранённый в БД результат препроцессора, применительно к процедуре: $(BEGIN_AUX) macro in DB (preprocessing result) А вот — отвлечённый пример надёжного выполнения инструкций T-SQL (с автоматическим перехватом исключения), НЕ SQL-ФАЙЛ: /* ПРОВЕРКА ИЗМЕНЕНИЯ ТАБЛИЦЫ [FILES] — УСТАНОВКА НЕСКОЛЬКИХ ПОЛЕЙ ОДНОВРЕМЕННО: */ :SetVar BEGIN "begin set xact_abort,implicit_transactions off; set ansi_nulls,ansi_null_dflt_on,arithabort,nocount on; begin try" :SetVar END "end try begin catch if @@trancount>0 or xact_state()=-1 rollback transaction; throw; end catch; end" $(BEGIN) /*================================================================================================*/ BEGIN TRANSACTION ---------------------------------------------------------------------------------------------------- update [FILES] set [XNUMBER] = -1, --[FILE_PATH] = '$(HomeDrive)$(HomePath)' -- только в настоящем SQLCMD [FILE_PATH] = 'C:\Users\serg' -- для запуска в SSMS where [ID] in ( 1, 3, 5 ) -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - select * from [FILES_LOG] order by [DateTime], [ID], [_ID] raiserror ('Искусственное исключение отката.',11,1) ---------------------------------------------------------------------------------------------------- COMMIT TRANSACTION /*================================================================================================*/ $(END) GO Выполнение инструкций данного скрипта ниже raiserror не опустится. Т.е. сработает перехватчик, завёрнутый в виде ключевого макрослова $(END) , см. :SetVar END … (Транзакция не будет зафиксирована; напротив — будет выполнен её откат.) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.12.2020, 13:12 |
|
Технология SQL-файл (для MSSQL)
|
|||
---|---|---|---|
#18+
Внимание! Развёрнута новая дискуссия на тему SQL-файл. Смотрите новую тему-продолжение (от 4 сентября 2021 г.): Технология SQL-файл, препроцессор для T-SQL, бок-о-бок файлы и др. https://www.sql.ru/forum/1338551/tehnologiya-sql-fayl-preprocessor-dlya-t-sql-bok-o-bok-fayly-i-dr — — — ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2021, 13:30 |
|
|
start [/forum/topic.php?fid=46&msg=40028155&tid=1684330]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
135ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 265ms |
total: | 503ms |
0 / 0 |