ブログ

１．事象
　ACCESSの単票フォームのレコードソースとしてSQLServerのテーブルを指定している。「Microsoft SQL Server Manager」を使い、このテーブルに次のような列を追加して、フォームで更新操作をしたらエラーが発生。

追加した列：　Ａ項目 　bit型 　null可

エラーメッセージ：データの競合

“このレコードは他のユーザーによって変更されています。[レコードの保存]を選択すると、他のユーザーによる変更を無視し、自分が行った変更を反映します。[クリップボードにコピー]を選択すると、変更したデータはクリップボードコピーされ、他のユーザによる変更が反映されます。必要に応じて、クリップボードのデータを張り付け、自分が変更したデータに戻すこともできます。”

なお、このエラーが出た時、もちろん操作をしているのは、自分だけです。

２．対処と原因

[対処]

　A項目 bit型 null可 　　→ 　　Ａ項目 bit型 null不可 (必須項目、初期値:0）

　nullを許容しない、必須項目とする事でエラーを回避しました。

[原因]
　はっきりした原因は不明。ネットで検索した対処方法によると、どうやら、ACCESSでリンクする場合、bit型のようなBOOL属性の項目は、必須項目にしないとダメなようです。裏でどんな動きをして、今回のようなエラーが発生してしまうのか。

　以下、思った事。

　bit型は、ACCESSのデータ型ではYes/No型になります。ACCESSのフォームにおいて、チェックボックスの値を格納する時のデータ型として、よく利用します。なので、データはYESかNOかの２択で、nullはありません。今回、該当のテーブルは、元々、ACCESSのmdbのテーブルで、ACCESSのアップサイジング機能を利用してSQLServerのテーブルに変換したテーブルです。追加した列のプロパティは、そのテーブルにおいて既存のbit型列にならって設定しました。既存のbit型列は"null可"になっていました。同じように設定して、結果、エラーが起きました。改めて既存のbit型列のプロパティを見直したところ、拡張プロパティが設定されていたので、全て同じように設定しました。

例えば、次の拡張プロパティ

AllowZeroLength : False
AppendOnly: False
Attributes:1
CollatingOrder:1041
DataUpdatable:False
MS_Format:Yes/No
etc..(拡張プロパティは18項目あり)

　これらを設定しても、状況は変わりませんでした。さて、なんだろう。

　アップサイジング機能で変換されたbit型の列は、nullを許容する設定でしたが、既存レコードには値が全て設定されていました。後で、「Microsoft SQL Server Manager」で追加したbit型の列は、既存レコードにnull値が設定された状態になり、システム側で強制的に値を設定しようとして、結果的にその動作が競合となりエラーになってしまったのでしょうか。
（根拠なし、想像です）

以上

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は無くさずに
に大切に扱う使うこととします。