おひさ。。
なんか気が付いたらカウンタがぐるぐる回って10000いきそう。すごい！
たまに検索エンジンに島流しされたらよろしくぅ～～
（ちな人気記事はSQLの副問い合わせみたいｗ

さて、表題通り。
AMAZONでTERRA MASTERの自宅NASを買いました。
NASは簡単に言うとサーバ。
最小構成でNTFS対応のLINUXを動かしてハードディスクをネットワーク上で管理することが目的。
（NTFSともLINUXとも限らないけどｗ　まーWINDOWS版はね。

■別にサーバなんていらないんだけど
　最近スマホでも音楽を聴きたくなったので
NASで管理してダウンロードできるようにしたかったのが目的なんだよね

■実際どうだったの？
　悪くないね。TOMCATもSVNも動くし、将来性ありそう。
RAIDも簡単にできるし。これ、使えるね。速度もLANだから早いし。

　外付けを三つ四つ付けてる人々なら一括管理でデータ消失リスクを潰すのもいいかなー。
設定も遊びレベルできるし。

■設定方法
　ほぼほぼマニュアル通り。指示通りでいけるし、
わかりにくくてもNASは情報量多いからいける。

使い方は難しいかな。PCでソフトからアップロードって考えるとドツボにはまるかも。
\\192.168.0.X\folderNameって感じでショートカットを貼ってドラッグアンドドロップって
考えればいい。ちなみにショートカット貼るとあとあと楽。

スマホからのダウンロードは専用ソフトを入れれば簡単。
まー日本語怪しいけどｗ（こういうのの日本語はサービスだから多少はねｗ

■おすすめ
　こういうサイトに島流しされる人々はデータの管理に頭を悩ませていると思うので
紹介してみました。
　SQLしてサーバして、ガチ勢を目指すんやｗｗｗｗｗｗｗ

表題通り。

directory.exists("C:\\TEST\\新しいフォルダー (3)\abc.txt - ショートカット.lnk");
としたら、なぜか結果がFalseになる。ファイルもあることをエクスプローラー上で確認したし、
パスも\\を\に直してアドレスに貼り付けたらリンクが開く。
……なぜだ。リンクだからか！？そんなことある訳ないが……。

■解決
……当たり前だよ。System.IO.directory.existsなんだから。
フォルダパスじゃないから当然Falseが帰る。

System.IO.file.existsに直しておこう。
疲れてるとこんなもんだなーもー。

表題通り。
結構SQLServerに載ってるT-SQLはちょっと変なので、他のSQLに乗り換えたとき疑問が発生することがある。今回はサブクエリ（副問い合わせ）のイコールについて調べてみた。

 SELECT
     ファイル名
 FROM D_ファイル
 WHERE ファイルID = 
     (
         SELECT
             ファイルID
         FROM D_ファイル単語
         WHERE 単語 = 'テスト'
     );

ってSELECT文を用意したんだが、なぜか副問い合わせしたファイルIDを取得する
SELECT文が一行しか取得できん。
なぜだ。

■調べてみた
----------------------------------------------------------------------------------------------------
Subquery Expressions

A SELECT statement enclosed in parentheses is a subquery. All types of SELECT statement, including aggregate and compound SELECT queries (queries with keywords like UNION or EXCEPT) are allowed as scalar subqueries. The value of a subquery expression is the first row of the result from the enclosed SELECT statement. In other words, an implied "LIMIT 1" is added to the subquery, overriding an explicitly coded LIMIT. The value of a subquery expression is NULL if the enclosed SELECT statement returns no rows.

A subquery that returns a single column is a scalar subquery and can be used most anywhere. A subquery that returns two or more columns is a row value subquery and can only be used as the operand of a comparison operator.
----------------------------------------------------------------------------------------------------
翻訳翻訳英語を翻訳ぅ～～！
----------------------------------------------------------------------------------------------------
サブクエリ式

括弧で囲まれたSELECT文はサブクエリです。 集合型および複合SELECTクエリ（UNIONまたはEXCEPTなどのキーワードを含むクエリ）を含む、すべてのタイプのSELECT文は、スカラ副問合せとして使用できます。 副問合せ式の値は、囲まれたSELECT文の結果の最初の行です。 つまり、暗黙の「LIMIT 1」がサブクエリに追加され、明示的にコーディングされたLIMITがオーバーライドされます。 囲まれたSELECT文が行を戻さない場合、副問合せ式の値はNULLです。

単一の列を返すサブクエリはスカラーサブクエリで、ほとんどの場所で使用できます。 2つ以上の列を返すサブクエリは行値の副問い合わせであり、比較演算子のオペランドとしてのみ使用できます。
----------------------------------------------------------------------------------------------------
はーん。要するにT-SQLとは仕様が違って、サブクエリを=参照すると一行だけ取得される仕様になっているわけだ。なるほどね－。
もう少し掘り進めてみると、=の代わりにINを使えばいいことがわかった。
（以下の章に詳しい。また相関サブクエリ等で検索すると理解が深まる。
・The IN and NOT IN operators
・Correlated Subqueries）
ちなみに似たような使い方でIN、NOT INまたはEXISTSを使うことが出来る。

……よくよく考えてみるとなんでT-SQLで=が使えたんだろうな。
こっちの方が文法的に合理的だし、わかりやすいよな。
しみじみとT-SQLはくs…謎だと感じるな。

■まとめ
・SQLiteでサブクエリを参照するときは1行のときに=、複数行の場合はINを使うこと。
・INの他に、NOT INやEXISTSを使用できる。

■照合順序の疑問
SQL Serverだとインスタンスを作成する際に照合順序の設定が出来た。
たとえばCI_とかだ。これを設定すると大文字小文字・半角全角・ひらがなカタカナが同一視されないようになった。

しかし、SQLiteだとどういう仕様なのかよくわかっていない。
本記事はこの仕様についてレポートする。


■公式サイトの記述
Datatypes In SQLite Version 3
https://www.sqlite.org/datatype3.html
以下のように記載がある
7. Collating Sequences
------------------------------------------------------
When SQLite compares two strings, it uses a collating sequence or collating function (two words for the same thing) to determine which string is greater or if the two strings are equal. SQLite has three built-in collating functions: BINARY, NOCASE, and RTRIM.

・BINARY - Compares string data using memcmp(), regardless of text encoding.
・NOCASE - The same as binary, except the 26 upper case characters of ASCII are folded to their lower case equivalents before the comparison is performed. Note that only ASCII characters are case folded. SQLite does not attempt to do full UTF case folding due to the size of the tables required.
・RTRIM - The same as binary, except that trailing space characters are ignored.

An application can register additional collating functions using the sqlite3_create_collation() interface.
------------------------------------------------------
意味わかんないなｗ翻訳しようｗ
------------------------------------------------------
SQLiteは2つの文字列を比較するとき、照合シーケンスまたは照合関数（同じものに対して2つの単語）を使用して、どちらの文字列が大きいか、または2つの文字列が等しいかどうかを判断します。 SQLiteには、BINARY、NOCASE、およびRTRIMという3つの組み込み照合関数が組み込まれています。

・BINARY - テキストのエンコーディングに関係なく、memcmp（）を使用して文字列データを比較します。
・NOCASE - バイナリと同じですが、ASCIIの26文字の大文字は、比較が実行される前に同等の小文字に変換されます。 ASCII文字だけが大文字に変換されることに注意してください。 SQLiteは、必要なテーブルのサイズのために完全なUTFの大文字小文字の変換を試みません。
・RTRIM - バイナリと同じですが、末尾のスペース文字は無視されます。

アプリケーションは、 sqlite3_create_collat​​ion（）インタフェースを使用して追加の照合関数を登録できます。
------------------------------------------------------


■まとめ
・BINARYはメモリ照合。大文字小文字半角全角ひらがなカタカナは同一視しないっすよ
・大文字小文字は全部小文字にして比較する（大文字小文字は同一視しますよ）
・メモリ照合だけど、末尾スペースは切り取るよ
ってことね。

ちなみにBINARYがデフォルトだから、
大文字小文字半角全角ひらがなカタカナが同一視される心配は無いということだ。


■補足１ BINARYがデフォルトだとしている記述
7.1. Assigning Collating Sequences from SQL
Every column of every table has an associated collating function. If no collating function is explicitly defined, then the collating function defaults to BINARY. The COLLATE clause of the column definition is used to define alternative collating functions for a column.

7.1. SQLからの照合順序の割り当て
すべての表の各列には、関連する照合機能があります。 照合機能が明示的に定義されていない場合、照合機能のデフォルトはBINARYになります。 列定義のCOLLATE句は、 列の代替照合関数を定義するために使用されます。


■補足２　LIKEについての注意点
……と思ったら=だと同一視されなかったんですが、やっぱりLIKEだと大文字小文字は同一視されるみたい……。サンプルプログラムを作ってテストしたから間違いない。
恐らくLIKEの仕様なんだろう（投げやり）。ま、=さえちゃんと効けば問題ないさ。


■書くときに参考にしたサイト
Django と SQLite/MySQL ： 照合順序を意識しよう
http://hideharaaws.hatenablog.com/entry/2015/03/17/160122
Datatypes In SQLite Version 3
https://www.sqlite.org/datatype3.html

最近、C#でSQLiteを使ってファイル仕分けソフトを作っている訳なんだが、ふと不明な点が出てきた。なぜかPRIMARY KEYにTEXT型を指定すると以下のエラーが表示される。

System.Data.SQLite.SQLiteException: 'SQL logic error or missing database


んーなんでだ。SQLiteってPRIMARY KEYにTEXT型は指定できないのか？



■SQLiteってPRIMARY KEYにTEXT型は指定できないの？
→結論から言うと、色々勘違いはあったけど、できる。



T-SQLだと、出来なかったよな。
実際にManagement Studioを使ってやってみると、以下のエラーが発生する。

---
create table friend(name text, old int, address text, primary key(name, old));

メッセージ 1919、レベル 16、状態 1、行 1
テーブル 'friend' の列 'name' の型は、インデックスのキー列として使用するには無効です。
メッセージ 1750、レベル 16、状態 0、行 1
制約を作成できませんでした。以前のエラーを調べてください。
---
※ちなみに上の構文は信用ある素晴らしい某サイトから借りてきました。ありがとう！

んー。T-SQLだと確か制約があって、文字数が指定されていないとエラーになったんだよな。
同じような仕様だからSQLiteでもエラーになるのか？

……いや、いくら何でもそんな訳ねーよ。文字列型の主キー設定できんとか原始時代かよ。
ということで色々と探す。めっちゃ探す。

■原因はこんな勘違い
……あれ、このエラーメッセージってPRIMARY KEYでエラーになっているんじゃなくね？
System.Data.SQLite.SQLiteException: 'SQL logic error or missing database

！！！
おい、bin/debugのSQLフォルダのSQLファイルが古いままじゃねーか。
そりゃSQL文が違うんだからエラー出るわ……

結局、bin/debug内のSQLを
create table friend(name text, old int, address text, primary key(name, old));
が入っている最新のものにしたら直った。


■色々あったけど
いやー直って良かった。
T-SQLだとTEXT型のカラムはPRIMARY KEYに出来なかったけど、
SQLiteだと出来るのね。勉強になりました。はい。

ちなみにこれにかけた時間。三時間。マジかよぅ……。