2010-09-22

『売上猫くん on MySQL』開発日記 - 番外12 - トリガの制約

CREATE OR REPLACE View はストアドプロシージャでは実行可能ですが、トリガから呼び出すと以下のようなエラーが返ります。

ERROR 1422: Explicit or implicit commit is not allowed in stored function or trigger.

ネット検索してみたところ、以下の命令を含むストアドプロシージャをトリガ呼び出しすると、暗黙のコミットが起こり、肝心のストアドプロシージャが実行されないらしいです。

ALTER FUNCTION, ALTER PROCEDURE, ALTER TABLE, BEGIN, CREATE DATABASE, CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, DROP DATABASE, DROP FUNCTION, DROP INDEX, DROP PROCEDURE, DROP TABLE, LOAD DATA INFILE LOCK TABLES, RENAME TABLE, SET AUTOCOMMIT=1, START TRANSACTION, TRUNCATE TABLE, UNLOCK TABLES

参ったな...。

参考:暗黙のコミットを引き起こすステートメント



関連リンク:『売上猫くん on MySQL』開発日記の記事一覧

2010-09-17

Officejet H470 の無線LANがおかしい

知人が「一昨日からHP Officejet H470(無線接続)で印刷できない」という。 このプリンタは本年8月に知人が購入したもので、軽量ポータブル、バッテリ可動可、無線LAN接続可能で2万弱(本体)というなかなかの優れモノ(いや、HPのプリンタは紙詰まりが多発することを除くと、なかなか良い)。
そこで復旧にトライ。先ず電源OFFができないので、電源コードを引きぬき、バッテリも外し、再度装着し、電源をいれる。 こんどはONに成功。 ところがやはりPCからは接続も印刷できない。 よくみると、プリンタのワイヤレスLANアダプタのランプが点灯していない。 これはこのアダプタが壊れたに違いない、と確信してHPに電話をかけると、「電源とバッテリとアダプタを抜いて3分待って、再度装着してください」とのこと。「そんなことやっても駄目だよ、LANアダプタの故障なんだからさぁ~」と思いつつ、渋々言われたとおりに3分待って装着、電源投入。

「ぬ、ぬ、ぬ、ぬぅ!!!」、なんと、LANアダプタのランプが青色に点灯するではないか。あっさり、印刷もできるようになった。
疑ってごめんなさい > 
 サポートの人

土屋

2010-09-15

ドメインにログインできなくなって泣かされる

 先日、64ビット版の Windows Server 2008 を Windows Server 2008 R2 にアップグレードしましたが、一見何の問題もなく成功したかのように思われたアップグレードも、イベントを見てみると結構エラーが出ていました。
 特に気になったのが、別サーバで運用している Active Directory ドメインコントローラから今回アップグレードした Windows Server 2008 R2 マシンがうまく対話しなくなってしまったので、一度 Active Directory のメンバから外して再登録をしてみたところ、ログイン不能となってしまいました。

 結論から言うと、OS のアップグレードを行うと Active Directory とクライアントマシンとのセキュアチャネルの一部に不整合が生じるため、これをリセットすると解決するようです。

良い例
 OS をアップグレードした後に、Active Directory ドメインコントローラを運用しているマシンから Active Directory ユーザーとコンピュータを開き、アップグレードを行ったコンピュータを右クリックし、サブメニューから「アカウントのリセット」を選択します。

 すると、アカウントがリセットされたコンピュータの再度起動時に認証情報の再同期が行われ、ログイン可能な状態となります(セキュアチャネルが修復されるので、認証絡みのエラーや警告がイベントログに記録されなくなる)。

悪い例(当方の失敗例)
 Active Directory ユーザーとコンピュータを開き、アップグレードを行ったコンピュータを右クリックし、サブメニューから「削除」を選択し、再度同名のコンピュータを登録すると、再起動時にセキュアチャネルが破損した状態となり、ログインできなくなります。
 よほどのことがないかぎり、コンピュータは削除しないようにしましょう。

 万が一、この手順でコンピュータを削除してしまったために、ドメインにログインできなくなってしまった場合は、下図のようにコンピュータを一度ドメインから外し(任意のワークグループに参加させるなど)てコンピュータを再起動し、再度ドメインに参加させるように構成するとセキュアチャネルが再構築されるようになります。


重要
 対象のコンピュータが証明書サーバ(証明書サービスをインストールしている)の場合、ドメイン変更やコンピュータ名の変更ができなくなるため、アカウントのリセットやコンピュータの削除を行う前に証明書サービスを一旦アンインストールする必要があります。

ドメインセキュアチャネルが破損しているかどうか調べる方法
 ドメインにログインしようとしたときに「サーバーのセキュリティ データベースにこのワークステーションの信頼関係に対するコンピュータ アカウントがありません。」というメッセージが表示されてログインできなくなっている場合には、セキュアチャネルに何らかしらの問題がある可能性があります。

 クライアントマシンのコマンドラインからセキュアチャネルのリセットを試みることで、セキュアチャネルが破損しているかどうか判断できます。

a. netdom コマンドを使ってリセット

 netdom reset /d:[ドメイン名]

例:netdom reset /d:local.jp
このコマンド実行が失敗する場合は、セキュアチャネルが確立されていない(破損している)可能性があります。

b. nltest コマンドを使ってリセット

 nltest [ローカルマシン名] /SC_Reset:[ドメイン名]

例:nltest MyMachine /SC_Reset:local.jp
このコマンド実行が失敗する場合はセキュアチャネルが確立されていない(破損している)可能性があります。