ファイルからDBに入力する場合、ファイルで使用されているコードがDBで使っているコードと一緒でなければならない。
しかし、ファイルがどのコードで書き出されているのかわかんないわけだから、困る。
テキストエディターで開けば、ちゃんと文字が見えるわけで、ほんなら、unicodeなのかと思って、そのまま入れようとすると、エラーがでる。
UTF-8に変換してファイルを新しく作ってみるが、それは、テキストエディターで開いてみると文字化けにしかならない。明らかに何かがまずいのだ。。。
＝エ＝）今まで、途中でうまくレコードが入らなかったのもおそらくは文字コードによるものだろう。
＝エ＝）やっぱり、目的のもの（アルファベットと数字）だけをいれてくようにしたほうがいいのか。。
＝エ）楽しようとするばかりで、横道それまくりのような。。。

ノエ；）久しぶりに泣ける映画を見た。
ノエ；）4分の1ぐらい見たら、涙がぼろぼろ出はじめて、
ノエ；）鼻水ぐしゅぐしゅだった。
ノエ；）まぶたが晴れていたくなった。
ノエ；）あんまりなくと、くたびれる。
ノエ；）今日は、ちょっとクターーッとしている。

つうか、ファイルに保存されているデータをDBにいれてから、目当てなカタチのテーブルに分けて作ってけばええんよね、実際。
ただ、postgresqlの場合、タブ区切りじゃないとあかんらしいので、コンマ区切りのものは返還してから使う必要がある。まぁ、そんだけやな、きっとこれの方が早いに違いない。

何度も何度も、同じような機能のコードを書いていると、前回書いたコードを再利用することが多くなり、機能を細分化してクラス分けしていくと、長いコードがだんだん短くなっていく。
いるのかいらないのかわからないが、InsertIntoというクラスを作った。
public String setInsertInto(String tablename ， String[] rows ， String[] values)
このメソッドを搭載させたいばっかりにだ。
データベースにデータを入れるコードを書くと、必ず毎回このコードはいるので、それなら、部品分けしちゃえと分けてみた。

＝エ）日曜日に半日ぐらいかけて東証1部をみてて、8つぐらいまで絞った中に、日立工機があったのだが。絶好の押し目買いのところにいたんだが．今日34円あげ。
単価が高いと敬遠しがちだけど、単価の高いものほど安定して上がる気がする．

java.lang.OutOfMemoryError
こんなもんはきだすコード書いちゃったよ．．．
＝エ＝）オブジェクトがでっかすぎるねんな。
＝エ）必要な文字だけを取り出して、配列に入れるオブジェクトをチッサクしたらいけるかもしれんな．．．

自分で日記を荒らしている気がする

同じ機能のコードを3度書き直した。
2度目は、動かなくなって、3度目はDBに入らなかったレコードのもとを記録できるような機能をつけた。だんだんよくなっているが、nullポインターの例外がでて、なにが原因かわからず、くじけそうになった。
で、最初のちゃんと動いたコードを見直して、DBに接続するメソッドを書くのを忘れていたのに気がついた。
DBにデータを入れるだけで、こんだけ苦労して、なんだか、だんだん、目的を忘れかけてる気がする。。。

毎日のデータを、まるごとテーブルに入れてしまって、後でそのテーブルからレコードをそれぞれのテーブルに割り振る。というやり方もある。
さらに、それを割り振らないで、処理のたびに日ごとのテーブルから検索して処理していくと言う方法もある。
でも処理が早いと思えるのは、一緒に処理するデータを一つのテーブルにまとめておく方だ。

今、日経平均が売りな流れなので、全体的に売り銘柄を探した方が儲かる。
1月15日に設定したポートフォリオも空売りの方がプラスになった。
実践だと、毎日ポジションを確認して、自分のポジションに合わなくなったと判断したら、ポジションを外していく。
それさえしたら、もう少し、成績が良かったはずだ。
でも、まだ、信用取引の準備ができてないので、見守るだけだ。

＝エ＝）今度のコードは
java.lang.NullPointerException
なんて、どうしてでるのかわからないエラーで、先に進めなくなった。
＝エ＝）調べてみたけど、DBにSQLおくるメソッドまで文字列はあるのに、
なんで出るんや。。。。
＝エ＝）ヒトッククリにするとあかんのかもしれない、、、また元に戻るw

insert intoを；で区切って一括でおくるコードを書いたけど、
これだと、ちゃんと入ったかどうか、selectして調べなあかんのかいな？
そんな単純な仕事はDBの方でやってほしいところ。
日付の列だけ入った、テーブルを用意して、各テーブルを連続して比較させる。
で、日付の入ってなかったテーブルのリストを作らせる。
トリガーってやつをつかえばええんやろか。

繰り返し命令の中で、約4600のレコードを何回問い合わせや、挿入、テーブルの作成の命令を出しているのか、考えてみたら、一回の操作で、何万回ぐらいになりそうな計算だった。。。。

・エ・）1レコードを挿入するのに、1回送信、そこですませて、結果まち、この動作を、4600回ぐらい連続して実行する。
＝エ＝）もしかしたら、DBの方が、レコードの書き込み結果報告の動作が追いつかないで、次々と命令が飛んでくるために、バッファーがフローして、あふれた分だけ、命令が実行されないのかもしれない。
＝エ＝）よく考えたら「；」で区切ってあれさえしたら、いくらでも連続してSQLを送信してもOKのはず。その方が、DBの方は一括で処理できるので、バッファーがオーバーフローするようなことも少ないのでは？？？
＝エ＝）ただ、この場合心配なのは、文字列の長さが長過ぎて、オーバーフローしちゃうかもしれないということだ。
＝エ＝）いずれにしても、やってみないとわかんねーか。
＝エ＝）しかし、WEBアプリのように送り主が個別に違うってわけではないので、
insert intoの連続をおくっても差し支えはないはずだ。
＝エ＝）全然気がつかないで、効率の悪いやり方をしていた。。。。

あー、おもうようにならない。
もう、直接コードをいじるて、一から実行より、今後のためにも、トラブルが起こったところをしっかり記録していく用意をするべきかもしれない。Loggerってクラスがあったっけ、あれを使うか。
テーブルがあっても入ってなかったり、ロジックが悪いのか、それとも、テキストデータがおかしいのか。。。
テキストデータも問題のある箇所だけを引き出して、通してみよう。

CSVでなら、ほとんどエラーがなく、データをインサートできるとはいえ、
全くないというわけではない。
そもそもなんでエラーが出る？？？
もしかしたら、検知されないエラーがあるかもしれない。
場当たりで書き出したコードなので、そこらへんは丁寧に書いていない。
＝エ＝）DBとちゃんと通信するか自体、自信がなかったから。
タブ割りのテキストファイルでやってみると、山のようにエラーがでた。
で、ターミナルを使って直接selectをして調べてみると、できているはずのテーブルができていなかったりする。
これはロジックがまずいのだ。
ひとまとめに書いてあったコードを4等分にわけて、DBにさせる作業ごとにprivateメソッドにした。
3重になっていた例外処理もすっきりとなる。
互いを呼び出しあって、回帰状態にならないように気をつける。
DBにほんとに受け入れられないレコードが存在したら、帰ってこなくなるからだ。
その4つのメソッドのうち2つを使うpublicメソッドを作る。
適当な名前が思いつかなかったからrun()ってしておいた。

＝エ＝）先週、から売り銘柄と買い銘柄の2通りを選んでおいたら。
今週、結果を見ていると　どっちもマイナス。
空売り銘柄を買い銘柄に、買い銘柄を空売り銘柄にしておけば、よかった。
これじゃ、話にならん。。。

タブ区切りのモノをやってみたら、インサートできないレコードが多数あった。。。
なにがいったいあかんのや。。。

・エ・）tableをtalbeと書いていたスペルミスでselectができなかった。
・エ・）参照整合性制約の特徴に合わせてロジックを書いていなかった。
・エ・）クォーテーションがつめていなかった。
・エ）この3つのおかげで、エラーがでていた。
・エ・）それでも2行（2レコード）ぐらいエラーがでることがある。
・エ）DBとアプリとの通信で起こる障害だろうか？？？
・エ・）DBとアプリは同じマシンだから考えにくいのだけど。
・エ・）今後はそれらインサートできなかったモノだけを、ファイルに記録しておくようにするといいだろう。
・エ）リトライ用のファイルにする。
＝エ＝）しっかり、データをいれるということは結構大変。