timestampが空欄をゆるさないのが本当でした。

mysql5.6以降、きちんとすることがきめられたようです。

すなわちtimestampが空欄は許さなくなったということです。

それ以前は空欄のチェックをしてもしなくてもmysqlが忖度して、自動的に現在の時刻を入力してくれていたのです。

mysql4.0.xはtimestampがは14桁の数字でしたが、mysql5.1以降は年月日時間分秒の表現になりました。

mysql 5.6 バージョン以降の厳しいtimestampの設定は、さらにmysql５．７では厳しくなりました。

timestamp　は　not　nul　default　CURRENT_TIMESTAMPとし、オプションで　update　on　CURRENT_TIMESTAMPとしないと認めてくれません。

さらに　mysql　>　select　explicit　from　defaults_for_CURRENT_TIMESTAMP　=　1という　設定を要求されてきました。

これからがとてもとめ大変な迷路に入ってしまうのです。

myql5.7へのデータ移行が大変な作業になってくるのでした。

これまでのmysql5.5へのデータ移行と比べると、格段に難しいのでした。

しかし、これはNavicatの使い方を研究することによって可能になりました。

別のページでご紹介致します。

毎朝のデータ移動がうまくいきません。SOAP入力がdeleteになります。

これは　timestampの設定がうまくいっていないのです。

チェックをしましょう。

やはりそうでした。院内のmysql5.7サーバーのデーターをチェックすると、データーの一部のtimestampが空欄であった。mysql5.6以降はその現象が起こることに注意が必要です。以前は、timestampが空欄になることはなかったのです。

むしろちゃんとしてきたということです。timestampが空欄、のnot　nullでなければいけなかったのにいい加減にしていてもmysql側が忖度して空欄のチェックをいれなくても勝手にnot　nullにしてくれていたのです。

最初からtimestampが空欄としないといけなかったということでしょう。！！！

もう一つは、カルテ移動の10個のテーブルがあるが、改造をする場合には特に注意が必要である。datumとsupportのフィールドの構造が一致していることが重要です。

最後に、myprodocの工夫の一つですが、自動増加autoincrementです。移動する10個のテーブルのうち「診療録」だけは、supportの自動増加はないのです。

しかしながらこの点も本当は自動増加にしないといけないのではないでしょうか

検証が必要ですね。！！！！？？？？

そのテーブルこそカルテ番号をつくるテーブルですので、これは特別です。データベースのプロパティをいじるときは要注意です。

今日、診療しながらクラウド型myprodocを実験してみました。

一番の問題は、カルテのスピードでした。クリックして作動するまでのインタバルが１－２秒ぐらいかかるのが気になりました。

オリジナルカルテはさくさく作動するのですが、私の改造カルテは、確かに動きが遅すぎます。

実際のmyprodocは①クリニックサーバー　ver.4.0.18ですが、実験のmyprodocは、②ver.　5.7と③クラウドのver.5.7

の3台ｐｃで行いました。

navicatでデータ転送して、3台とも同じデータ同期させ、それぞれをmyprodocで開いてみました。

大体カルテは開くのですが、細部まで開いてゆくとテーブルによっては、データが部分的にうまく表示されていないものもあります。文字化けはないようです。

文字は、ver.4.はsjis、その後ver.5.1はutf8そしてver.5.7は

utf8bm4へと設定していますので、化けなくなりました。

mysqlの文字設定は、テーブルさらにカラムのひとつひとつで設定可能ですので、古いバージョンで作成されたデータがその条件を保持されているので、修正が必要なデータもでてくるようです。

バージョンアップ後はしばらくは微調整が必要となることを覚悟しないといけないようです。

ついに　できました。

odbcが開かなかったのは、ANSIと　の選択でANSIを選んだためだったのです。

Unicodeを選んだところ文字化けなくodbc接続し、Myprodoc.accbdbが開きました。ここで　account.mdbもxserverにodbc接続し、vbaの参照設定もaccount.mdb（Xserver）を選びなおしました。

ただカルテの開くスピードがとても遅いのがきになります。

自宅でteamviewerでカルテをみているせいもあります。

明日、クリニックで実際のスピードを体感してみたいと思いますが、

一段落です。！！！！！

navicatでデータ移行可能しかもwindows4.0.18から5.1そして5.7にデータ移動可能でした。さらにXSERVERにもデータ移動し、そしてodbc接続も可能でしたが、accessで見ようとすると、英語のテーブルは見れますが、しかし,odbc　日本語を認識していないようです。

やっと気づいた　XSERVERとは、Linuxのデータ移行でした。

Linuxのデータをwindowsで使用するということです。

Linuxのwindows　accessへのodbcがうまくいっていないということです。

この点の研究が必要なことがわかりました。Navicatデータ移動成功

Xserverとクリニックのパソコンとの通信はRLoginのおかげでできましたし、

ACCESSとのodbc接続がなかなか完成しません。テーブルのリンクが完全にならないのです。よく観察すると、日本語をリンクできないのです。

詳細な分析をするには、慣れたnavicatが使用できればいいなあと思っておりました。ついにnavicatでデータ移動ができるようになったのです。

さらにテーブルリンクが困難な理由は、文字設定でutf8がその名の通りでなく８バイトである日本語や中国語は認識できないそうです。mysql5.5以上は、utf8bm4が使用でき、文字化けが解消するそうです。

結論は、①RLoginnで通信OK、②navicatでデータ移行がok、③文字化けはnavicatでutfbm4設定とする。となりそうです。

ついについにクラウドで電子カルテが開いたのです。

odbc　adminisutratorでは、データーベースに接続してもカルテのテーブルが全然みえなかったのです。

そこでXSERVERに付属しているphpmyadminを使用してみました。

面白い機能がありました。mysqlのdumpしたsql文を　drag　and　dropすると、テーブル登録が数分ででき　sucess　のメッセージがでたのです。

そしてaccessからodbc接続を試みると　テーブルリンクができるではないでしょうか

ついにカルテが開きました。

もっともっと簡単な方法があると思います。

ダンプリストアがもっと簡単にできるようになり、ftpパネルでデータのパーミッションを必要最小限に行うなどの練習か必要と思います。

今回はパーミッションも　７７７レベルで行ったので、セキュリティ上は危険なレベルでした。

とにかく　一段階終了しました。

mysql5.7へのデータ移行ができました。

当院のバージョンはmysql4.0.18でしたが、XSERVERのバージョンは5.7です。

問題は文字化けでしたが、sjisからutf8に変更するので、mysql5.1を経由するのが楽に移行できるようです。

その手順は次の通りでした。

１、3台のパソコンに、それぞれのバージョンのmysqlをインストールします。２、navicatを用いて、まずmysql4.0.18からmysql5.1へデータ移動を開始。

それぞれのdatabase　datum、image,master、supportを移動します。

なんなく移動できます。次にmysql5.7へデータ移動を行います。これも文字化けなく成功しました。

しかし問題はこれから　accessにodbcリンクを作成しましたが、テーブルが見えないのです。

もう一息ですがどうしてでしょうか？？？

データ移行はmysql4.0.xからmysql5.7に行おうとしていますが、

いろいろな方法がありますが、navicatによる方法で行っております。

まずmysql5.0に移行することに成功しました。

構造がどんどん変わってゆくのです。まだmysql5.0はdataの場所が一緒です。5.1からdataの場所が分かれるのです。

文字化けとのたたかいとtimestamp問題が大きな問題ですので、バージョンアップしてゆくうちに最新の状態になるのです。

XSERVERと当院のパソコンがRLoginで接続成功しました。

RLoginは32bit　バージョン版と64bitバージョン版の二通りがあり、

32bit版でも接続できました。当院のaccessは32bitバージョンですので、odbcも32bit版を使用しました。

データべースのサーバーのアップロードは、FTPソフトホームページビルダーを使用して、FTP転送を利用して、アップロードを行いました。

しかしカルテは開きませんでした。

XSERVERのmysqlは5.xバージョンなのです。当院のmysqlは4.0.18バージョンでしたので、データアップグレードが必要なのでした。