長らくご愛顧いただきました当ブログですが、この度移行することにいたしました。
なぜ移行するのか
このブログ、BlogEngine.NETを使っていたのですが、正直使いにくいところがありました。
ただ個人的な要件があり、それらを満たすものがコレくらいしか見つからなかったということもあり、なんだかんだ だましだまし使ってまいりました。
ですがさすがに限界が来ており、この度Github pagesを利用したブログを開設することにしました。
専用のブログサービスを使わず、Github pagesを使う理由ですが「手元のソースをプッシュして公開する」という形にしたかったからです。
ブログサービスに乗せてしまうと、どうしても記事や構成がサービスに依存してしまい、再度移行したいときに不便そうなのと、サービスの方針に振り回されてしまうのが怖いので、それを避けたいという理由があります。
まあそれはGithub pages を使っても同様なのですが、影響は最小限ですむかなーと考えております。
このブログの今後について
削除する予定は当面ありません。
というより、記事を出力できなかったので移行できない＝＞削除もできない の流れです。
がっでーむ。
時間が経てば考慮しますが、すくなくとも一年やそこらで削除するつもりはありません。
別ブログで、ということになりますが、今後ともよろしくお願いいたします。
Tags :
自分メモ。
ディスクサイズの使用状態を日時のログで吐き出す。
実際使う時はタスクスケジューラあたりで呼び出す。
Get-PSDrive -Name C | Select-Object @{Name='datetime'; Expression={Get-Date -Format('yyyy/MM/dd')} } , Used, Free | ConvertTo-Csv -NoTypeInformation |Select-Object -Skip 1 |Out-File -FilePath 'Drive_C.txt' -Append
もっと簡単なやり方があったはずだが、「Windows Server 2008R2で動く」という本来あってはならない要件があり、試行錯誤してた結果こんなんを書いていた。
SSMSの表示が正しくないとき（時々あるよね）案件。
問題
SSMSでログインのプロパティを覗いていたら、既定の言語が「Arabic」になっているものがあった。
Arabicかー、珍しいなー、と思ったが引っかかったのでSQLを投げて確認。
select name, default_language_name from sys.server_principals
う～ん、ひとつだけ浮いている方がいますね。
一人だけ素のenglish。ハイ、これがArabicだったログインです。
そしてログインを作っているSQLの中身を見てみたら既定のデータベースを「english」で指定していました。
多分us_englishで指定すべきところをenglishで指定した結果、ログインは作成されたけど言語の一覧にないのでプロパティ画面のコンボボックスがセット処理が正しく走らず、一番上の「Arabic」になったと思われます。
https://docs.microsoft.com/ja-jp/sql/relational-databases/system-compatibility-views/sys-syslanguages-transact-sql?view=sql-server-ver15
※記事投稿時点ではリンク先の表示が崩れてます
ちなみに、他のログインは既定の言語を指定しなかったのでデータベースの規定値を引っ張ってきて正しく設定された模様。
似たようなバグもあったけど
最初、コレかな？と思ったSSMSのバグもあったけどタブン違う。
* https://docs.microsoft.com/ja-jp/sql/ssms/release-notes-ssms?view=sql-server-ver15
* https://feedback.azure.com/forums/908035/suggestions/38236363
教訓
経験上、既定のデータベースの表示がおかしくなることもあるよ！
SSMSは便利だけど、疑問解消・原因調査の際はSQLで！
Tags :
10. 2月 2020 23:02
/
丘山大一
/
Blog . プログラミング . VBA
コメント (0)
VBAでプロシージャ呼び出しの際、引数に括弧をつけるのかつけないのか・つけたらどうなるのかが異様に分かりづらかったので真面目に調べました。
というか自分の整理のためにまとめました。
参考にさせて頂いたのは
布団が俺を呼んでいる | Firebird のお勉強 FSQLの使い方
自分メモ。
うまく言えないんですが、
aaa
bbb
ccc
ddd
というテキストを
aaa bbb
ccc ddd
に変換してファイル出力する感じ。
こんなん
$originalFilePath="hogehoge.txt"
$filePath = "fugafuga.txt"
[int]$count=0
Get-Content $originalFilePath | ForEach-Object {
$count+=1
If($count % 2 -eq 0){
Write-Output($_) | Out-File -FilePath $filePath -Append -Encoding utf8
}else{
Write-Output($_ + "`t") | Out-File -FilePath $filePath -Append -NoNewline -Encoding utf8
}
}
13. 10月 2019 09:10
/
丘山大一
/
Blog
コメント (0)
exeファイルのプロパティのセキュリティにアクセスできなくなる現象とも。
ファイルを削除しようとすると、
「このファイルを削除するには管理者の権限が必要です」→「続行」→
「この操作を実行するアクセス許可が必要です」→「再試行」→
以降ループするので「キャンセル」せざるをえなくなる
リネームしようとすると、
「このファイルの名前を変更するには管理者の権限が必要です」→「続行」→
「この操作を実行するアクセス許可が必要です」→「再試行」→
以降ループするので「キャンセル」せざるをえなくなる
実行しようとすると、
「指定されたデバイス、パス、またはファイルにアクセスできません。これらの項目にアクセスするための適切なアクセス許可がない可能性があります」
で、メッセージ内容から「セキュリティが変なのか……」と考えファイルのプロパティからセキュリティを
開くと、たしかに権限がふられていない。ファイルの所有者の所有者も見えない。
しかし、権限をふろうとしても権限をふれない。
どういうこっちゃねん。
原因
他のユーザがexeファイルをロードしている状態で、さらに別ユーザがexeファイルを削除していたため。
原因詳細
エクセルファイルなんかで「別のプログラムがファイルを開いているので操作を完了できません」を見ることがあった人も
多いと思いますが、その複雑版です。共有フォルダに配置した、複数のユーザがたたくexeファイルで起きました。
登場人物は下記。
- Ａユーザ：exeファイルを実行していた人
- Ｂユーザ：exeファイルを先に削除した人
- Ｃユーザ：管理者であり、exeファイルを削除したい人
Ａユーザは、Ｃユーザのマシン内の共有フォルダに入ったexeファイルを実行しています。起動後なので、exeはロードが終わった状態です。
続いて Ｂユーザは、そのexeファイルを削除します。Ａがexe実行中でもファイル削除できます（Ｂのエクスプローラからは消える）
最後にＣユーザが共有フォルダに入ったexeファイルを削除を実施しますが上記「現象」にはまり何もできなくなります。
Ｃマシン内の共有フォルダにあるexeは、Ｂによって削除された亡霊みたいな状態。
対応
exeにアクセスしている人を強制的に全部切断すれば解消されます。
というか先に切断しておきましょう。
泣き言
これWindowsのバグでは、という気がしなくもない。けど何かしら事情があってこうなっている気もする。