ODBCを介してMySQLサーバーに接続され、複数のユーザーがアクセスするMicrosoft Accessデータベースがあります。
時間が経つと、多くのレコードがロックされ、編集できなくなります。
すべてのレコードを一括でロック解除する方法はありますか?
エラーメッセージ:
このレコードは、編集を開始してから別のユーザーによって変更されています。レコードを保存すると、他のユーザーが行った変更が上書きされます。変更をクリップボードにコピーすると、他のユーザーが入力した値を確認して、変更を行う場合は変更を貼り付けることができます。
最終的に問題を解決できましたタイプTIMESTAMP
のtimestamp
という名前のフィールドとデフォルト値_CURRENT_TIMESTAMP
_および_attribute = on update CURRENT_TIMESTAMP
_を追加します。次に、すべてのレコードを更新してTIMESTAMP=NOW()
を設定します。
とりあえず、エラーは出ませんでした。
これをトラブルシューティングするために、覚えておくべき非常に重要な情報を以下に示します。
MySQLのロックは、行、テーブル、アドバイザリ/名前付きロック、さらにはグローバルなFLUSH TABLES WITH READ LOCKであっても、ロックを取得した特定の接続スレッドが存在し続けることで保持されます。ここで「接続スレッド」とは、クライアントからサーバーへの接続の特定のインスタンス、つまりロックが要求されたインスタンスを意味します。これらは、SHOW FULL PROCESSLISTにリストされているスレッドです。
要求している接続が適切に閉じられると、その接続によって要求されたすべてのロックがすぐに解放されます。
特定の接続スレッドが管理者によって強制終了された場合(mysql> KILL#;#は強制的に切断するSHOW FULL PROCESSLISTからのID)、そのスレッドがSHOW FULL PROCESLISTから消えるとすぐにロックが解放されます。
その接続が正常に閉じられない場合、接続は最終的にタイムアウトし(変更しない限り、デフォルトは28800秒です)、ロックが解放されます。
行とテーブルのロック できない 最初にロックを取得した接続が存在しない場合でも存続します...したがって、MySQLには、時間の経過とともにロックが蓄積し、ロックを解除する必要のあるものはありません。
クライアントがロックを不適切に保持している場合でも、ロックが理由で存在するため、クライアントの切断を強制することが唯一の回避策です...データの整合性を保つためです。切断を強制しても、すべてのユーザーがログアウトするわけではありません。これは現実的ではないためです。上記のKILLコマンドを参照してください。
私の推測では、AccessはMySQLからの応答を正しく解釈せず、 考えている レコードは実際には別のものである場合にロックされます。
すでに確認されているように、Toad、HeidiSQL、Query Browser、Workbench、または単にmysqlコマンドラインを使用してこれらの行の値を更新できるはずです。そして、問題なくそれらを更新できる可能性が非常に高いです。 。それらが実際にはロックされておらず、Accessが混乱していることを証明します。
ユーザーがAccessから見ているメッセージの正確な文言を投稿することは、おそらく問題に正確な光を当てる最良の方法でしょう。
NULLのビット(またはブール)値がないことを確認したい場合があります。何らかの理由で、それらはAccessの頭を台無しにしています。解決策は、提案されたタイムスタンプか、ブール値にデフォルト値を与えることです。少なくともこれが、MS SQL Serverに接続されたデータベースでこれが発生する原因です。 MySQLでも同じように面白いビジネスだと思います。
まだ1つのTIMESTAMPフィールド(たとえば、tablefieldと呼ばれる)がある場合は、デフォルト値と属性のないDATETIMEに変更します。次に、(たとえば)TIMESTAMPという新しいTIMESTAMPフィールドを作成します。デフォルト値はCURRENT_TIMESTAMP
で、属性はonupdate CURRENT_TIMESTAMP
です。
元の変更されたTIMESTAMPフィールドの前に使用すると、次のようなトリガーで現在のタイムスタンプを取得できます
CREATE TRIGGER `justnow` BEFORE INSERT ON `tablename` FOR EACH ROW set new.tablefield=now()