Kobarin's Development Blog

C#やASP.NETなどについての記録です。

SSMSのレコード編集を「上位200行の編集」でなく任意のSQLで抽出する

SSMS上で簡易的にレコードの編集を行う場合の操作として、テーブルを右クリックすると「上位200行の編集」というメニューがあります。
これですとレコード数が200行のを超える場合は対応できない上、目でレコードを確認しながら操作するため、誤って別のレコードを変更してしまう危険もあります。
そこで、任意の条件で抽出したレコードに対して編集を行う方法を説明します。

  1. 編集したいテーブルを選択
  2. 右クリックして「上位200行の編集」
  3. レコードの一覧が表示されたら、メインメニューの「クエリデザイナー → ペイン → SQL」の順で選択
  4. するとSQLのエディタが表示されるので、WHERE句を付け足して任意の条件を記述します(例: where id = 123)
  5. 記述を終えたら画面上部のSQL実行ボタンを押します
  6. レコード一覧(単レコードであれば1行のみ)が表示されるので、目的の値を変更

ASP.NET Core でWebページ→PDF変換

ASP.NET MVC 5.0の時には、WebページをPDF化する際にTuespechkinを使っており、Azure上でも動作していました。
今回.NET Core 5.0のリリースを機に調べたところ、Tuespechkinは.net framework用のライブラリなので、ASP.NET Coreに対応するPDF変換ライブラリが新たに必要になります。

ASP.NET Core上で動作するPDF変換ライブラリ

Syncfusionというライブラリが見つかりました。
help.syncfusion.com
上記サイトの手順通り進めれば導入は可能で、Nugetでもインストールできます。
ただし、私の環境でそのまま実行すると、

PdfDocument document = htmlConverter.Convert("https://www.google.com");

の部分で「HTML conversion failed」となり変換に失敗するため、次の項で説明します。

SSLhttps)用のライブラリが必要

エラーメッセージからは原因がわからなかったのですが、原因はSSL用のライブラリが無い事にあります。
そのため、上記のGoogleのアドレス部分を非SSLサイトのURLに置き換えると難なく変換できます(これが分かるまで1日かかりました)。
Html to pdf conversion using webkit failed when accessing https page | WPF Forums | Syncfusion
の公式の回答にある通り、OpenSSLのライブラリをインストールするだけで解決しました。
インストールすると、以下3つのライブラリがシステムディレクトリ内に入ります。

  • libeay32.dll
  • libssl32.dll
  • ssleay32.dll

32bitのようにも見えますが、64bitにも対応しているようです。

終わり

以上の操作で再度SSLサイトのURLを実行したところ、無事に変換できました。
まだAzure上での動作確認はしていませんので、でき次第追って報告します。
なおTuespechkinの頃に使ったマージンや向きといった設定は、WebKitConverterSettings のMarginやOrientationで可能です。

Azure SQL Database で、DBの照合順序の変更方法

Azureでは、SQL Databaseを新たに作成すると、照合順序がデフォルトとして「SQL_Latin1_General_CP1_CI_AS」になるため、
その後にTABLEにvarchar型などの文字列フィールドを作成すると、そのままだと全て「SQL_Latin1_General_CP1_CI_AS」になる(照合順序は、データベースと文字列フィールド別々に指定できる)。
例えば後から「Japanese_CI_AS」に変更する場合、フィールドに対して直接ALTERする事で対応するしかなくなる。
列の照合順序の設定または変更 - SQL Server | Microsoft Docs

ALTER TABLE dbo.MyTable 
ALTER COLUMN CharCol VARCHAR(50) COLLATE Japanese_CI_AI

フィールドの追加の度にこれでは流石に運用に難が生じるが、通常は「DBの照合順序は後から変更できない」とされる。
ただし、実は「データ層アプリケーションのインポート/エクスポート」を使う事で、”データベースの照合順序”の変更が可能である事がわかったので、ここから説明する。
情報源はこちら。
stackoverrun.com

方法を準に説明すると、以下の通り。ここではDB名は「MyDB」とする。

  1. SSMSでAzure のSQLに接続し、目的のDBを右クリックで「データ層アプリケーションのエクスポート」を実行(→MyDB.bacpac ファイルがダウンロードできる)
  2. MyDB.bacpacファイルのコピーを作成(例:MyDB.bacpac → MyDB2.bacpac)
  3. MyDB2.bacpac のファイル名を変更し、MyDB2.zip にする(実はbacpacとは、zipの拡張子を変えただけのファイル)
  4. 7-zip等を使ってzipを展開し、model.xml を開く(メモ帳でOK)
  5. 先頭の方に「Name="Collation" Value="SQL_Latin1_General_CP1_CI_AS"」となっている箇所があるので、Value部を「Japanese_CI_AS」に変更し、保存
  6. 次に、Origin.xml の Checksumの変更が必要なので、コマンドプロンプトで「CertUtil -hashfile "<model.xml の パス>" SHA256」を実行(参考: SQL AzureでエクスポートしたbacpacをローカルのSQLサーバーにインポートすると SQL72014が発生する - Qiita)し、得られたコードをOrigin.xml 内の「<Checksum Uri="/model.xml">ここに貼り付け</Checksum>」に貼り付ける。
  7. MyDB2内を再び圧縮し、MyDB2.zipが出来たら、MyDB2.bacpac にリネイム(注意:MyDB2を圧縮する際、7-zipでフォルダに対して圧縮すると、そのフォルダが余計に作成された形で圧縮されてしまい、後述するインポート時に「'Origin.xml' が dacpac パッケージにありません」とエラーが出てインポートできなくなるため、MyDB2フォルダ内のmodel.xmlを含む全ファイル&フォルダを選択して圧縮する)。
  8. SSMSに戻り、MyDBをいったん別のデータベース名に変更して退避させ(例:MyDB_backup)、「データベース」を右クリックし「データ層アプリケーションのインポート」を実行。
  9. 完了したら、MyDBのプロパティで照合順序が「Japanese_CI_AS」になっている事を確認して終了

Azureでwkhtmltopdfがサポートされた話

Webサイト上からHTML(URLで指定)をPDFに変換する処理にwkhtmltopdfを使う場合、従来Azureでは動作しなかったらしい。
調べてみると、以下の投稿が見つかった。
social.msdn.microsoft.com
ただし、

Azure now supports WKHTMLTOPDF. Please make sure you're using Basic, Standard, or Premium App Service Plan.

とあるように、Freeでは非対応らしい。
試したところ、たしかにFreeでは動作せずBasicでは出来た。

Visual Studio 2019からAzureにDeployできない問題

Visual Studio 2019からAzureにDeployする際、以下ののエラーとなる。

Web deployment task failed. (The type initializer for 'Microsoft.Web.Deployment.DeploymentManager' threw an exception.

状況をまとめると以下の通り。

  • ASP.NET Coreのプロジェクトをテンプレのまま何も編集していないため、コードや設定に問題があるわけではない
  • Buildは正常にできるものの、PublishでAzureにDeployする際に上記エラーとなる
  • Azureポータルで確認すると、インスタンスは出来ている(従って、https://XXXXXX.azurewebsites.net/ のサイトは存在するが、サイトは動作しない)

冒頭のエラーについて調べてみると、以下の投稿が見つかった。
stackoverflow.com
この中の以下のReplyが気になった。

I had the same problem but installing SQL 2012 and changing the registry didn't fix it. After reinstalling Web Deploy 3.5 on my development machine things got straightened out.

気になった理由は、ここ以外にも「Web Deploy」が問題になるという内容の情報が見つかったからだ。
そこで「プログラムの追加と削除」を確認してみると、以下の2つが見つかった。

  • Web Deploy 4.0
  • Web Deploy 2.0

古い2.0を削除し、再びVSのDeployを行った結果、無事に成功。う~ん、エラーメッセージもっと具体的に出してほしい。

【解決済み】SQL Server 2014の再インストール時「sql server データベース エンジンの復旧ハンドルの待機に失敗しました」エラー

概要

久々にSQLServerを動かそうとしたところ接続できず、管理ツールのサービス「SQL Server」も停止したまま起動できなかったため、SqlServer2014を再インストールしようとした。

症状

インストーラーからインストールを実行したところ、以下のエラーが発生した。

sql server データベース エンジンの復旧ハンドルの待機に失敗しました」

インストール結果としては、データベースエンジンだけがインストールに失敗している。

対策1:全て削除してから再インストール(解決できず)

「プログラムと機能」より「SQL」と名の付くアプリケーションを全て削除して再度インストールを試みたが改善せず。

対策2:「SQL Server データベースエンジン」のアカウント変更(解決!)

以下を参考に実行したところ、無事にインストール成功した。

www.sk-access.com

SQL Server 2016 SP1 Express」のインストールの途中で、「サーバーの構成」が表示されます。
サービスの
「SQL Server データベースエンジン」のアカウント名が
「NT Service\MSSQL$SQLEXPRESS」になっています。
この「SQL Server データベースエンジン」のアカウント名を
「NT AUTHORITY\NETWORK SERVICE」に変更します。

信頼レベル「Medium」(Medium-Trust)のサイトでは、ASP.NET MVCが実行できない可能性

私が個人的に契約しているWindowsホスティング会社に、MVCサイトを発行し実行したところ、セキュリティエラーが発生しました(System.Security.Policy.PolicyException)。
Visual Studioの開発環境で試してもエラーが出ないため、ホスティング会社に確認したところ「信頼レベルは”Medium”」だとの事なので、その辺りを疑ってみました。
VS上で同じ環境を作って試すため、web.config内に以下の行を付け加えてみました。

<system.web>
  <trust level="Medium" />
</system.web>

その結果、VSの開発環境でも同様のエラーが発生しました。



冒頭で発行したとするMVCのサイトは、VSで自動生成されたMVCサイトのままでほとんどに手を付けていない状態。
信頼レベルの制約で疑わしい点があるとするなら、

  1. OAuth
  2. 外部APIXML)へのアクセス
  3. SqlServerへのアクセス

程度ですが、2及び3については、既に発行済のASP.NET WebFormsで実行済みなので除外しました。
とすると、残るはOAuthのみ(他にあるかもしれないけど、それがダメならMedium-Trustって何も出来ないと同義ですよね)。


そこで、「こういう事例って他に結構あるのか?」と思い探してみると、こんな書込みが。
どうやら「ASP.NETの開発チームの公式見解としては、Medium-Trustは時代遅れ」という事です。
stackoverflow.com
理由としては、

  1. 「修正不可」とされていたMedium-Trustにまつわるバグを全て解決済み(デバッグではなく、Full-Trustにより解決したと思われる)
  2. ホスティング会社に対して、Medium-Trustから移行し、代わりにOSレベルの適切な分離をするようにガイダンスを提供済み
  3. これまで開発してきたフレームワークMVCやWebAPI等)からMedium-Trustのサポートを中止済み。今後これらのフレームワークにより作られたアプリケーションにはFull-Trustが求められる。

としている。つまりMedium-Trustは使うべきではないアクセス制限機能ということになります。
なお、ここでの「Medium-Trust」というのは「信頼レベル=Medium」というだけでなく、「Full」より下の「High」「Medium」「Low」「Minimum」の4つを全て含む総称としている点に注意です。


実際、このような書込みもあります。
stackoverflow.com
この中のリプライに

But, most of hosting provider offer full trust hosting now

とあるように、Full-Trustが米国(?)では一般的なようです。
ASP.NET MVCサイトのホスティング先をお探しの方は、あらかじめ運営会社に「信頼レベル」を確認していただく事をオススメします。