スタッフの日記

1.事象
　Windows7のパソコンにおいて、タスクスケジューラで毎日実行していたバックアップ処理が出来ていない事が発覚。とりあえず、実行記録を確認しようとタスクスケジューラを起動したらタイトルのエラーが発生。エラーメッセージの応答で[OK]をするが、引き続き同じメッセージが表示される。
この操作は数十回繰り返した。おそらく、設定されていた多くのタスクに対してメッセージが表示されたと考えられる。バックアップ処理が出来ていなかったのは、このタスク設定が壊れてたためと断定。

2.原因調査と対処
　とりあえず、タスクスケジューラの設定を元通りにする対処方法をネットで検索。同様の事象は過去にも結構出ているらしい。以下のサイトを参考に対処してみる。

　　タスクスケジューラを開くとエラーメッセージが表示される「タスクスケジューラサービスが利用できません」
　　http://answers.microsoft.com/ja-jp/windows/forum/windows_7-performance/%E3%82%BF%E3%82%B9%E3%82%AF%E3%82%B9%E3%82%B1/fde068e5-d1d5-4821-9888-b2270a428e6f?auth=1

　[対処：　”タスクのインポート”操作でタスクの再設定]
　C:\Windows\System32\Tasksフォルダ配下の全ファイルを任意の場所に移動してタスクスケジューラを起動。エラーは出なくなった。ここから、全部のタスクをインポートで再設定することにした。TasksフォルダにはWindowsやパソコンベンダー等のフォルダ配下に100を超える設定ファイルがある。気が滅入りながらちびちびやっていると、設定ファイルのタイムスタンプで気づきが・・。どうやらバックアップ処理が失敗した日の直近で更新されている設定ファイルが破損しているらしい。まず、設定ファイルのタイムスタンプをみてインポートしないで元に戻せるか判断。これでだいぶ楽になった。

　[タスクイメージが破損した原因（多分）：　Windows10->Windows7のダウングレード]

　しかし、以下のエラーが発生してインポート操作で復旧が出来ないタスクが出てきた。

　“タスクの形式が有効ではありません。(2,8):version:1.5”
　

　ネットを検索。以下が参考になりました。

　　タスクスケジューラーで「タスクの形式が有効ではありません」と表示され作成できない
　　http://answers.microsoft.com/ja-jp/windows/forum/windows_7-update/%E3%82%BF%E3%82%B9%E3%82%AF%E3%82%B9%E3%82%B1/b20e1938-22ee-4fce-8f71-db4fa66dcf50?auth=1

　確かに、破損している設定ファイルのタイムスタンプは、Windows10からWindows7に戻したタイミングと一致している！
　おそらく、元に戻す課程で破損してしまったのではなかろうか。但し、　原因が分かったところで、戻せないタスクがあるってことは問題だな。そのタスクが何をやっていたのかも分からないし。
　
　　Microsoftめー、またやってくれたなー。

　おそらくWindows10にしてから元のＯＳに戻したパソコンは、こうなっている可能性が大。　一度、タスクスケジューラを起動して確認してみることをお勧めします。

ブラウザ側入力フォームで指定した日本語文字列をAjaxリクエスト(POST)でサーバに渡した際、サーバ側で参照したら文字化けを起こしていてハマりました。

jQuey日本語リファレンスをみると、サーバに送信するデータはクエリー文字列に変換されてGETリクエストとして付加されるとあったので、URLエンコードは自動的にやってくれると思いましたが、POSTの場合はこちらで変換した値を指定してあげないとダメなようです。
以下、サンプル。日本語が入力されている「cSearchKeyWord」をencodeURIで変換してdata：{・・・・}に指定してます。

 var cSearchKeyWord = encodeURI(document.form001.cSearchKeyWord.value.trim());
 $.ajax({
  type:"POST",
  url:"送信URL",
  dataType:"html",
  data:{
   "cSearchKeyWord":cSearchKeyWord,
   "cHashTags":cHashTags,
   "cFromID":cFromID,
   "cToID":cToID,
   "nRetweetFlag":nRetweetFlag,
   "cGetCount":cGetCount
  }
 }).then(
  // 通信成功
  function(data,status,xhr){
  ・・・・
  },
  // 通信失敗
  function(xhr,status,error){
  ・・・・
  }
 );
 
この結果にたどり着くまで、えらい時間が掛ってしまいました。phpのmb_stringとかhtmlの文字コード設定やら、php.iniの文字コードに関わる設定とかを改めて見直しました。結局、中途半端な知識で仕事をしてきているからハマると一から調べなおす事になってしまう。ネットで検索できて便利なのだけど、頭にちゃんと入らないんですよね。いかんなぁ・・・・。

（mdbでリンクする際、[固有レコード識別子の選択]は正確に行いましょう）

■事象
ACCESSのMDBで、SQLSERVERで定義しているViewをODBC接続でリンクした。
ACCESSで表示したところ、SQLSERVERのVIEWの表示が一部の列で値が違って表示されている。

例)

以下のようなView_TEST をMDBでリンクしたところ、表示した"単価"、"個数"列がSQLSERVERのViewと違って表示されている。

View_TEST:

select 店舗,販売日,品物,単価,count(*) as 個数 from TEST group by 店舗,販売日,品物,単価 order by A.

[SQLSERVERの表示]

[ACCESS MDBの表示]

　　※　3行目の単価、個数が198、13のはずが、2行目の値になっている。

■原因と対応
mdbでリンク指定する時に、[固有レコード識別子の選択]という操作があり、そのテーブルの主キーとなる項目を設定するのですが、この項目の選択が誤っていました。今回の場合、group byで集計していたら集計した列を全て指定しないと一意になりません。結果、おかしな表示になってます。(なぜ上記のような表示になるのかは疑問が残るが、そこは追及する意味がないと判断。)

以前から、[固有レコード識別子の選択]は結構いい加減に考えていて、適当に設定していても問題なかったのですが、今回の不具合で改めて重要であることを認識しました。というか、ちゃんと理解して設定しろよ！正しく理解する為の時間を惜しんで、結局遠回りして痛い目に遭う。
（こんな事、結構繰り返してます……OTL）
 

Access2010まで提供されていたSQL Serverへのアップサイジング機能
（アップサイジングウィザード）が、Access2013では削除されてしまいました。

　※Office 2013 での変更点
　　https://technet.microsoft.com/ja-jp/library/cc178954.aspx

処理速度改善の案件で、システムはLAN環境でAccessデータベース(mdb)をサーバに配置して
クライアントPCのGUI画面から読み書きをしていたのだけど、Jet Database Engineの処理の
仕方でどうしても処理速度が上がらないため、SQL Serverに移行してしまおう
（無償のExpress Editionバージョン）となりました。

　そこで出番となったAccessの素晴らしい機能であるアップサイジングウィザードです。
これを使えば、テーブルとそのデータだけでなく、インデックス、入力規則、テーブルの
リレーション等も一緒にSQLServerのデータベースに移行してくれます。
大変便利です。ところが。。。。表題のとおり。仕方がないのでAccess2010がインストール
されている別のマシンで処理しました。

　移行の代替案としてSQLServerのインポート機能を利用しようと思いましたが、
これだどテーブルとそのデータだけなんですよね。

なぜ、MicrosoftはAccess2013で削除してしまったのか理由は分かりません。
今後のAccessバージョンで復活してくれることを願いつつ、Access2010は無くさずに
に大切に扱う使うこととします。