Технология SQL файл, препроцессор для T-SQL, “бок-о-бок” файлы и др

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

В качестве вступления предлагается прочитать короткую заметку о презентации технологии SQL-файл на SQL.RU (от 15 декабря 2020 г.):
Технология SQL-файл (для MSSQL)
[del] (форум – Microsoft SQL Server).

	Комментарий модератора
	Ссылки на сторонние форумы запрещены! См. п. 5.8 Правил форума

I. Предыстория (что не так с языком Transact-SQL, расширения SQLCMD и др.)

Автор данной статьи в течение долгого времени взаимодействовал с СУБД MS SQL Server. Когда-то в прошлом к автору данной статьи пришло осознание того, что режим исполнения инструкций (Control Flow) в языке Transact-SQL, который MSSQL предлагает по умолчанию (режим), не является надёжным. Без использования специальных блоков-обёрток для перехвата исключения — необходимо везде-везде проверять состояние последней ошибки @@ERROR. Исходя из желания использовать эффективный (полуавтоматический, с исключениями) контроль ошибок, а также и по другим (тоже веским) причинам, в течение длительного времени вырабатывалась и применялась интересная технология SQL-файл, основанная на расширениях SQLCMD. SQL-код хранится в файлах, организованных специальным образом в виде SQL-проекта (в дереве вложенных файловых папок). Для трансляции файлов в базу данных применяется легковесный обработчик — препроцессор-конкатенатор скриптов: SqlCatPP (EXE) в связке с вызывающей его обёрткой $SqlTrans (CMD). Так же, подразумевается использование вспомогательной библиотеки элементарных хэлпер-объектов и констант (вида “$(<ПеременнаяСреды>)”) SQLAUX (в приложение к основному транслятору/препроцессору). В качестве редактора SQL в настоящее время, помимо встроенного редактора Far-Manager, а также одного из GUI-редакторов для простого текста (см. в загрузках), доступно так же использование SQL Server Management Studio (+Environment), в немного ограниченном, однако, виде (см. устройство “SSMS.cmd” в загрузках).


II. Технология SQL-файл на страницах https://handicraft.remelias.ru/

Вот ссылки на страницы автора статьи (минимальное описание + картинки и примеры):
https://handicraft.remelias.ru... ots_1.html (Скриншот-ы SQL-файл: 1, 2, 3);
https://handicraft.remelias.ru/sdk/sql_file.html (Технология SQL-файл; Список хэлперов SQLAUX);
https://handicraft.remelias.ru/sdk/sql_tools.html (Легковесные инструменты SQL).

Ещё картинки (вспомогательное применение SQL-файл, бок-о-бок файлы SQL/C# и др.):
https://handicraft.remelias.ru... t_orm.html
https://handicraft.remelias.ru... s_sql.html


II.1. Запуск SQL-файлов с учётом подготовленного окружения

После настройки, проведённой соответствующим образом, легковесных инструментов, появляется возможность “запускать” правильно сконфигурированные (снабжённые лежащим в том же каталоге “$sql_settings.cmd”) файлы кода с усиленным Transact SQL. В Far-Manager подобная трансляция срабатывает (приводится в действие) из панели по <Enter> (для ассоциации SQL), из встроенного редактора по <Ctrl+Enter> (простейший макрос); в отдельном окне (запуск из панели) — по <Ctrl+PgDown>, в отдельном окне (запуск из встроенного редактора) — по <Ctrl+F12>. Утилита $SQLTRANS “подхватывает” “$sql_settings.cmd”; файлы из подкаталогов, как правило, наследуют (и, возможно, расширяют) сеттинг-и (окружение) более высокого уровня расположения. Корневой же “$sql_settings.cmd” подключает, как правило, “SQLAUX.cmd” (из каталога библиотеки), а также “@<имя_проекта>.cmd” (в UTF-8). Запустив же SQL Server Management Studio посредством стартера “SSMS.cmd” (располагается в корне SQL-проекта), данный процесс также получает возможность использовать все тонкости настроенного окружения:
— Доступны слова для обёртки основного блока: $(BEGIN_AUX), $(END_AUX), с автоматической защитой от ошибки (т. н. “заворачивание” в “begin try”/“end try”/ … и т. д.), которые, так же, инициализируют некоторые T-SQL-установки SET (при раскрытии “$(BEGIN_AUX)”);
— Многочисленные ключевые слова и константы: $(LOOP_AUX), $(TRUE_AUX), $(DropFunctionScript_AUX), $(num_IntStrMaxLength_AUX), $(dt_Name_AUX), и т. п.;
— Ссылки на собственные переменные проекта “$(<ИмяПеременной>)”.

Необходимо сначала должным образом установить и настроить поддержку SQL-файл!!!
— При установленном плагин-е для Far Manager CmdCpAuto, появляется возможность комфортно просматривать (по F4) многочисленные CMD (с автоматическим переключением на нужную кодировку).
— После прописывания в системе пути (PATH) к командным утилитам “…\HandicraftSDK\CMD-utilities” (папка с CMD, EXE) — становится работоспособным следующее: $sqltrans.cmd, $sqlupload.cmd, $sql.cmd, $sqlcon.cmd, $sqltocsvexp.cmd и прочие “$”-команды.
— Так же, в системе потребуется определить путь к библиотеке скриптов и констант окружения SQLAUX: SQLAUX_ROOT = …\HandicraftSDK\SQL\SQLAUX.
— При установленных макросах LUA из “HandicraftSDK\CMD-utilities\Shell\Integration(\RU)”, а так же после настройки ассоциаций FAR-а согласно “!Integration of $SqlTrans with FAR Manager.txt” (или “RU\!Интеграция $SqlTrans с FAR Manager.txt”) — всё становится довольно-таки удобным для программирования с применением SQL-файл.

Обратите внимание на папку(и): “HandicraftSDK\CMD-utilities\Shell\Integration(\RU)”.


II.2. Трансляция множеств (файлы SQL)

Помимо простой трансляции отдельного файла, имеется возможность обработать группу / подгруппу SQL. Для запуска подобной трансляции применяются, как правило, простые стартеры CMD. В одну трансляцию могут попадать не только файлы шаблона “*.sql”, но также (при соответствующем запуске $SqlCmd) и сразу несколько подпапок, а также и некоторый специальный SQL-файл. Порядок обработки файлов перестраивается посредством простейших файлов коррекции “$sql_order.list”. Сложные же (составные) трансляции описываются соответствующими CMD-сценариями. Подобные сценарии играют в SQL-файл значительную роль (удаление файла, запрос подтверждения, формирование текстового отчёта, и т. п.)

В загрузке, соответствующей Handicraft-SDK, присутствуют три условных SQL-проекта (перечислены в “SQL-project-list.txt”), а в состав “BookRegistry app.” входит один сложный (из 2-х разнесённых частей) SQL-проект.


II.3. Слабый и сильный препроцессинг (осуществляется подпрограммой SqlCatPP)

При использовании Environment зачастую нормальным будет положиться на поведение базового средства SQLCMD. По умолчанию (при обращении к $SQLTRANS) SqlCatPP (EXE) применяет так называемый “слабый препроцессинг”, затрагивающий одну лишь директиву “:SetVar”. Он попросту добавляет перед ней одну строчку-комментарий: –:SetVar … (чтобы иметь неиспорченную диагностику относительно номера строки ошибки). Однако, когда Вы не взаимодействуете с БД напрямую, а отдаёте свои скрипты дилеру (посреднику), то возникает потребность в тщательной подготовке такого скрипта, с учётом Environment SQL-проекта. (Навряд ли удастся на стороне дилера использовать какие-либо окружения.) В данном случае необходим так называемый “сильный препроцессинг”, который реализуется в SqlCatPP в тестовом виде, затрагивает директивы “:SetVar”, “:r”, а также ссылки на переменные среды: “$(<ИмяПеременной>)”. Результат подобной обработки доступен для примера в подкаталогах $OUTPUT и $GENERATED проектов SQLAUX и “Extralight-ORM test legacy sample (En+Ru)\MyFlat app. (MVC_Razor+TS+ADO+TSQL)\SQL (DB-modelling)”. В состав “sqlaux_library.sql” (из $OUTPUT), например, входят (как минимум) 173 исходных SQL-скрипта (фрагменты с разделителем GO), присутствующие так же и в $GENERATED (с порядковым префиксом имени файла: “XNNN.<BaseFileName>.sql”).

Так же, утилита $SQLTRANS имеет возможность производить фиктивную трансляцию (“set $sqltrans.TranslateToDatabase=0”), выводить данные в текстовый файл результатов (для этого необходимо задать действительный 2-й параметр, например: $SqlTrans “%~n0.sql” “%~n0.txt”), а также поддерживает передачу дополнительных параметров в базовый SQLCMD (например: “set $sqltrans.AdditionalParams=-y0”, “set $sqltrans.ContinueOnBatchError=1”). И не только это (см. страницы, картинки и загрузки).


II.4. Два основных направления в использовании SQL-файл

Технология SQL-файл применяется для достижения следующих 2-х основных целей:

1) Хозяйственная обработка базы данных MSSQL: добавление таблиц, наполнение их данными, правка структуры БД, прочие рутинные операции административного характера. Поскольку всё оформляется в виде файлов, то то или иное действие может быть повторно воспроизведено впоследствии (с соответствующей доработкой скриптов).

2) Программирование в базе данных MSSQL, а именно — написание подсистемы хранимых объектов кода SQL (процедуры, функции, триггеры, представления), которые в терминологии SQL-файл обозначаются как “программатики” (общий термин). Серверную SQL-часть приложения принято, зачастую, генерировать целиком — удалять все (или подгруппу) программатики (соответствующие, например, такому-то именному префиксу) и создавать их заново. (Данное действие можно производить на разных экземплярах сервера и БД, указываемых в корневом “$sql_settings.cmd” соответствующего SQL-проекта.)


III. Небольшая попытка создания экспериментального псевдо-микро-ORM для доступа к своим SQL-запросам и ХП, бок-о-бок файлы (SQL/C#) и прочее

III.1. Техника Side-by-Side (SQL/C#)

В экспериментальных проектах “Client-Server.WEB (idea)” а также “MyFlat app. (MVC_Razor+TS+ADO+TSQL)” была предпринята небольшая попытка непрямого соединения исполняемого SQL-сервером кода Transact-SQL с исполняемым веб-сервером ASP C#-кодом для .NET. В 1-м случае подобный CS-код, так же (с учётом соответствующих директив условной компиляции), работает в браузере (применяется WASM-Blazor), что привносит дополнительные усложнения. Каждый запрос к БД оформляется в виде 2-х рядом лежащих файлов с одним и тем же базовым именем: “<ИмяЗапроса>.sql” и “<ИмяЗапроса>.cs”. В данном случае под SQL-запросом понимается код хранимой процедуры T-SQL, который “попадает” на сервер в момент трансляции SQL-файла, каталога с файлами либо всего большого проекта (с применением $SqlTrans+SqlCatPP).

Соединение SBS-файлов условное (смешения кода нет). Данное исполнение стремится видеть (представлять) SQL-запросы в довольно унифицированной форме: с параметрами ХП, статусом возврата “@Status uniqueidentifier = null out” (параметр), сообщением ошибки “@Message $(dt_Message_AUX) = null out”, с возможными несколькими резалт-сетами. (В последующей неопубликованной версии аналогичного SDK данные параметры имеют, соответственно, имена “@RStatus” и “@RMessage”.)

Легковесный ORM к ХП и SQL-запросам (Handicraft-CODE):
https://handicraft.remelias.ru... t_orm.html

Попытки успешного смешивания разнородного кода известны. Например: “.razor” и “.cshtml” (смешение HTML+C#) — используются для генерации HTML-разметки посредством C#, с частичной проверкой правильности разметки. При компиляции же SQL-процедуры (например, из файла SQL) — также проводится определённая проверка правильности SQL. Совмещение SQL+CS возможно было бы, в определённой степени, усовершенствовать. Например, в некоторых трудоёмких случаях — использовать объявление параметра (с типом) по месту его применения в теле запроса, “поручив” оформление заголовка(ов) запроса(ов) генератору-препроцессору SQL (добавив в него соответствующую функциональность). Так же, используя специальный вспомогательный формат двойственного (SQL-сервер/SQL-клиент) определения значений и типов, теоретически возможно было бы достичь определённого успеха. Однако, смешивание кода, работающего в совершенно разных средах и местах, навряд ли должно выглядеть просто.

В примере “BookRegistry app.” излишнюю сложность, однако, привносит использование JSON, а также желание надёжно “защититься” (проверки-исключения) от Null-ов на стороне C# (после передачи данных через HTTP в упакованном виде, посредством JSON). В примере же “MyFlat app. (MVC_Razor+TS+ADO+TSQL)” применяется сочетание 2-х языков для наименований: английский (ASP веб-сервер) <=> русский (объекты в SQL-БД).


III.2. Зачем всё это нужно (или же почему не всё так складно в ORM)?

Данный пункт можно отнести к области фантастики. Он предполагает существование возможности вносить изменения/дополнения в некоторую реляционную СУБД, поддерживающую расширяемый диалект языка SQL.

В настоящее время, при доступности применения ORM для взаимодействия с БД, её (одну из ORM) естественно будут использовать очень многие. Несмотря даже на то, что подобное применение зачастую ведёт к определённому перевороту, когда, например, язык C# может быть поставлен выше базы данных, как принято на это смотреть в контексте применения EF Code First, и любое общение/взаимодействие с БД (даже не от имени разрабатываемого приложения) подчиняется уже C# и особенностям Entity Framework (при использовании Code First). А ежели подход с центральным Code First — это востребованное передовое, то всё, что не Code First — уже не годится (не то, что надо) и т. п. Есть и другие причины, также говорящие в пользу применения своих SQL-запросов для общения сервером SQL. (Крупные базы данных, кстати, способны пережить и несколько клиентских фреймворков и ORM.)

Что же касается использования хранимых процедур в БД для приложения, то существует обоснованное мнение, что это (1) не современно, (2) не кроссплатформенно, а также (3) тяжело в поддержке. Поэтому — опять приходим к ORM, большому ORM. (И даже микро-ORM применять, как правило, обычно не рекомендуется.)

Непростая идея компилируемых запросов SQL:

Бок-о-бок файлы (приводятся выше), реализованные автором статьи в экспериментальном виде на базе классических хранимых процедур-запросов MSSQL, могли бы, так же (потенциально), при должной поддержке со стороны СУБД, быть исполнены, по части обработки SQL, в виде так называемых “компилируемых запросов SQL” (Compiled SQL Queries с ограниченным управляемым временем жизни), поддерживаемых гипотетическим SQL-сервером (с функцией Compiled SQL Queries). Компилируемые SQL-запросы возможно было бы унифицировать по части заголовков с параметрами-значениями, параметрами-таблицами, резалт-сет-ами, кодом/статусом/сообщением возврата и т. п. (Т.е. — такие специальные кроссплатформенные по отношению к диалектам SQL заголовки для SQL-запросов.) Хранящийся в SQL-файле клиента SQL-сервера параметризованный код (параметры запроса + клиентская Environment) должен соответствующим образом подготавливаться (“на лету” при первом запуске запроса, или, возможно, на старте приложения):
— сначала (на стороне клиента SQL) — применение аналога Environment SQL-проекта;
— далее (на стороне клиента) — препроцессинг SQL (раскрытие аналогов переменных среды);
— затем — подготовка на SQL-сервере, с проверкой ошибок (компиляция аналога временной ХП с параметрами, со специальным уникальным наименованием временно сохраняемого запроса).

Исправление же кода в файле с SQL-запросом приложения на работающей программе (желательно это делать, конечно, не в части заголовка) — должно восприниматься как необходимость повторной компиляции (когда потребуется) временного запроса: уничтожение/создание временного запроса+имени на сервере SQL.

Таким вот примерно образом автор статьи представляет себе общение с базой данных SQL на языке SQL, со стороны программы (например веб-сервера), использующей какой-либо компилируемый либо скриптовый язык. Для работы такого приложения потребуется технология, подобная SQL-файл (обозначим расширение как “SQL-file-app.”). Компилируемые запросы приложения (SQL-файлы) могли бы заранее (на этапе разработки) проверяться специальными командами трансляции (отсылаться на сервер) на предмет ошибок предварительной подготовки (компиляция запроса на стороне SQL). Более того: базирующиеся на SQL-файлах компилируемые запросы должны быть доступны из папок SQL-проекта для исполнения их отдельно от, собственно, приложения, — как из подготовившего запрос файла сценариев, так и из специального проверочного или хозяйственного SQL-скрипта, работающего в контексте того же (подготовившего запрос) SQL-подключения.

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


IV. Завершение (резюме)

Как было обозначено в начале пункта III.2, то, о чём (в п. III.2) фантазируется автором статьи, весьма удалено от нашей реальности. И всё же (насчёт реальности): несмотря на могущество отдельных диалектов SQL, длительную историю знаменитых СУБД, трудно, в контексте понимания того, как обычно оформляются/выглядят запросы к базе данных (SQL-вкрапления в другую программу, либо посредством драйвера большой и умной ORM, либо же с применением отдельного SQL-файла или объекта с кодом, открываемом в консоли-редакторе БД), — трудно называть SQL первосортным языком программирования, который мы можем полноценно поддерживать (с тем же комфортом, что и классические языки ОП), когда применяем SQL для взаимодействия с БД из кода приложения или из отдельного скрипта.


Китаев Сергей Юрьевич
Автор ресурса Handicraft-CODE
https://handicraft.remelias.ru/

Блог автора (Handicraft-CODE):
https://blog-hc.remelias.ru/

Оригинальная версия статьи в авторском блог-е:
Технология SQL-файл, препроцессор для T-SQL, “бок-о-бок” файлы и др.
https://blog-hc.remelias.ru/sq... files-etc/

Технология SQL-файл на сайте автора:
https://handicraft.remelias.ru/sdk/sql_file.html
https://handicraft.remelias.ru/sdk/sql_tools.html
https://handicraft.remelias.ru... ots_1.html
https://handicraft.remelias.ru... ots_2.html
https://handicraft.remelias.ru... ots_3.html

— — —

0

Сила — в скриптах (а именно в их количестве)

Небольшое отступление. Исходники, соответствующие бинарным утилитам SQL-file, располагаются в папках “Auxiliary programs (sources)\Command line\**” пакета HandicraftSDK. Так вот, каждый такой “маленький” проект C# снабжается вспомогательными командами на базе CMD. В Вашем распоряжении оказываются: build.cmd, rebuild.cmd, clean-all.cmd, test.cmd, build-n-run.cmd и т. п. Запустивши (щёлкнув мышью в Windows Explorer) $console.cmd, Вы можете воспользоваться полными или сокращёнными именами команд: ca (clean all), cr (clean + rebuild), … Полноэкранная консоль с вертикальной прокруткой хорошо подходит для автономной компиляции MSBUILD / dotnet build, помимо, так же, простого вызова CMD-файла в консоли Far Manager. В подобном проекте C# дополнительные сеттинг-и прописываются в #settings.cmd (UTF-8 без сигнатуры), а сам проект .CSPROJ снабжается так же вспомогательными .PROPS, .TARGETS, .USER (последний подхватывается автоматом, как расширение проекта .csproj или .vcxproj). Польза от процессора CMD заключается здесь в количестве прилагаемых скриптов, которые, несмотря на присущие CMD недостатки, удаётся-таки поддерживать / заимствовать / корректировать и т. п., что навряд ли было бы столь же легко и удобно, если бы использовался какой-то другой (более современный, продвинутый) интерпретатор командной строки. Так что (касательно CMD) можно сказать, что вся сила в скриптах, достаточно простых, чтобы их сопровождать, и которых нужно много.

(Кстати, в интерактивном режиме CMD так же доступно консольное псевдо-окошко последних вызовов, открывается по F7, — это помимо перебора стрелками вверх-вниз по месту самой команды с указателем “>”.)

Почему везде Far Manager.
Тот, кому приходится взаимодействовать с CMD (поддерживает скрипты командной строки), может по-настоящему ощутить полезность Far Manager: его оперативный встроенный редактор с т. н. колорёр-ом (синтаксическая раскраска), правильное отображение символов, выделение вертикальных блоков (Alt + стрелки) и т. п. Для работы с командными скриптами — FAR это естественная среда, как правило, совместимая со всем тем, что имеет отношение к слову текстовая консоль.

0

Ещё одно, элементарное, применение утилиты $SQLTRANS

Средства технологии SQL-файл возможно задействовать в разной степени. Не обязательно создавать т. н. SQL-проект (сеттинг-и: $sql_settings.cmd + @<project_name>.cmd). Во-первых, можно обойтись одним лишь $sql_settings.cmd, указывая в нём лишь параметры подключения: set $sql_server=…, set $sql_database=… и т. д. (Потребуется так же нейтрализовать в $sql_settings.cmd один или два вызова с импортом сеттинг-ов: проекта и, если оно чем-то мешает, библиотеки SQLAUX: “rem call :CALL_SETTINGS_BATCH …”.)

Однако, можно и вовсе не использовать файлы CMD. Для этого в системе или родительском (для запуска SQL-трансляции) процессе ОС следует определить переменные подключения к серверу SQL. Поддерживается авторизация 2-х видов: (1) через интегрированную безопасность Windows; (2) авторизация самим сервером SQL.

1) Пример задания переменных для случая с интегрированной безопасностью:
$sql_server = (local)
$sql_database = TEST

2) Пример задания переменных в случае авторизации сервером SQL:
$sql_server = (local)
$sql_database = TEST
$sql_user = SA
$sql_password_var = TestDB_SA_Password
TestDB_SA_Password = …

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

При использовании Far Manager следует воспользоваться настройкой ассоциации для расширения SQL: по Enter (из файловой панели, с предупреждением), по Ctrl+PgDown (из файловой панели); а так же: по Ctrl+Enter (из редактора, с предупреждением, макрос Editor_CtrlEnter.lua), по Ctrl+F12 (из редактора, макрос Editor_CtrlF12.lua). См. инструкции: “HandicraftSDK\CMD-utilities\Shell\Integration\RU”, файлы “!*.txt”.

В Far Manager есть возможность применения пользовательского меню (вызывается по F2). Можно задействовать конструктор меню (F2,Insert; F2,F4), а можно редактировать непосредственно FarMenu.ini: “%FARPROFILE%\FarMenu.ini”, либо в текущей папке (для локального меню). См. пример меню Far Manager: “HandicraftSDK\CMD-utilities\Shell\Integration\RU\FarMenu.i ni”. Так вот, в подобном меню Вы можете прописать несколько инициализаторов переменных (серия команд вида “set <variable_name>=…”).
Пример инициализации переменных $SQLTRANS посредством файла FarMenu.ini (фрагмент):
[[
: Инициализация переменных подключения к БД
set $sql_server=(local)
set $sql_database=TEST
rem set $sql_user=SA
rem set $sql_password_var=TestDB_SA_Password
set $sql_settings_script=-
]]

Ежели используется единственная БД, то параметры подключения можно задать глобально, в пользовательском профиле системы. Хотя, подобное упрощённое определение не рекомендовано (из соображений безопасности при применении трансляций SQL-файл).

Так же, помимо “запуска” отдельного файла, возможно обрабатывать группу SQL (без задействования файлов CMD), путём набора в командной строке следующей команды (например): “$sqltrans *.sql”.

В примере инициализации переменных посредством файла FarMenu.ini (см. выше) присутствует строчка: “set $sql_settings_script=-”. Эта необязательная установка устраняет автоматическое “подцепление” к скрипту инициального батч-а с настройками: “HandicraftSDK\CMD-utilities\$sql_settings.sql”. Скрипт $sql_settings.sql из каталога CMD-utilities содержит (пока в него не вписано иное) одни лишь комментарии, а также разделитель GO. Подобные настройки возможно располагать и в каталоге проекта (в файле $sql_settings.sql. Однако, это не рекомендуется делать по причине отсутствия совместимости с SSMS (фирменный исполнитель скриптов от MS не предусматривает подобных хитростей). В случае же подключения определений библиотеки SQLAUX, автоматическое подцепление инициальных сеттинг-ов в виде файла SQL по умолчанию нейтрализуется (командой из библиотечного CMD): “set $sql_settings_script=-”.

Насчёт исполнения батч-ей утилитой $SQLTRANS в плане возможной ошибки. До тех пор, пока не будет включена опция “set $sqltrans.ContinueOnBatchError=1”, до этих пор можно не волноваться за “немного сомнительные” скрипты SQL, которые SSMS генерирует по имеющемся объектам БД (для создания объекта), где в начало скрипта добавляется батч с командой “use [<Имя БД>]” и разделитель GO. Отсутствие на сервере указанной в скрипте базы данных ведёт (в данном случае) к ошибке, которая рассматривается как причина для прекращения обработки батч-ей: sqlcmd: -b (terminate batch job if there is an error). Таким образом, потенциально ненадёжная, как и многие другие команды T-SQL (в режиме по умолчанию) команда переключения текущей базы данных не представляет в данном случае опасности (того, что последующие инструкции отработают в отличной от указанной в скрипте БД).

Утилита $SQLTRANS (как и вся SQL-файл) довольно тесно совмещается с фирменной IDE SSMS. Например, при отсутствии сигнатуры (BOM) в исполняемом файле SQL, его содержимое будет восприниматься как в кодировке UTF-8, что совпадает с кодировкой по умолчанию для генерации файловых скриптов в SSMS. При желании же возможно трактовать отсутствие сигнатуры у скрипта SQL как содержимое в системной однобайтовой кодировке ANSI (CP-1251 при русскоязычной локализации). Для этого следует “выключить” умолчание UTF-8: “set SqlCatPP.DefaultInputEncodingUTF8=0”. (Настройки конкатенатор-а/препроцессора SqlCatPP наглядно выводятся батч-ем синтаксиса: “HandicraftSDK\CMD-utilities\Assemblies\SqlCatPP\!syntax.cm d”.)

Однако, несмотря на возможность неприменения пользователем файлов CMD при исполнении скриптов, рекомендованным способом для трансляции в SQL-файл является всё же сопровождение каталога (с файлами SQL) хотя бы одними лишь простыми сеттинг-ами в виде файла $sql_settings.cmd (см. примеры). Так же, желательно оставить в нём (не блокировать комментарием “rem …”) подключение библиотеки SQLAUX, содержащей набор существенных, хотя бы для потенциального использования, определений (свойства-переменные), таких как $(BEGIN_AUX), $(END_AUX), $(BEGIN_TRANSACTION_AUX), $(LOOP_AUX), $(NL_AUX) и т. п. См. папку: “HandicraftSDK\SQL\SQLAUX\API (headers)”, т. н. псевдозаголовочные (описательные, для пользователя) файлы SQL. Помимо раскрывающихся слов усиленного T-SQL, в каталоге присутствуют так же и заголовки всех библиотечных программатик-ов (сохраняемые в БД объекты SQLAUX, предназначенные для расширенного полноценного применения скриптовой библиотеки).

В ОС Windows-XP существовала возможность настраивать именованные ассоциации для расширений файлов. По правой кнопке мыши на файле SQL можно было (когда-то) выполнять действие Translate. В настоящее же время (как было и в прошлом) навряд ли удастся подобрать для технологии SQL-файл, ориентированной (в текущем исполнении) на консоль и файлы CMD, более достойный и совместимый с ней командный пульт (плюс оперативный редактор скриптов), нежели известный файловый командер Far Manager.

0