1

PHP で実行しているストアド プロシージャに問題があり、4 日間連続して自分 (およびテクニカル サポート) の頭を悩ませています。おそらく、これに光を当てるのを手伝うことができます。

簡単に言うと、ローカル コンピュータ ( ) で定義されたストアド プロシージャがありますspcTest。PHP ページは問題なく実行できるため、単一行のレコードセットが返されます。運用サーバーで手順を再作成すると、PHP ページで同じ結果が得られません。

これはパーミッションの問題だと確信していますが、特定するのに苦労しています。phpMyAdmin を介して運用サーバーにアクセスでき、そこですべての作成スクリプトを実行します。また、ストアド プロシージャ spcTest が本番環境に表示され (を使用SELECT * FROM ROUTINES)、それを正常に更新することもできます。

次のコマンドを実行すると:

SHOW GRANTS FOR triis@localhost;

これらは、それぞれ開発サーバーと本番サーバーで取得した結果です。

~~~=== 開発サーバー上 ===~~~

GRANT ALL PRIVILEGES ON *.* TO 'triis'@'localhost' IDENTIFIED BY PASSWORD '*F05[~~(snip)~~]72'

GRANT ALL PRIVILEGES ON `tri_is`.* TO 'triis'@'localhost'

~~~=== 本番サーバー上 ===~~~

GRANT USAGE ON *.* TO 'triis'@'localhost' IDENTIFIED BY PASSWORD '*F05[~~(snip)~~]72'

GRANT ALL PRIVILEGES ON `tri_is`.* TO 'triis'@'localhost'

GRANT USAGE開発側に存在しない -lineの違いに注意してください。私はmySQLのドキュメントを読んだことがありますが、答えを見逃している可能性があります...要するに、私の質問は、上に表示されているように本番サーバーでの権限を実行し、ストアドプロシージャの実行を許可することspcTestです?

私には、 -attribute が特に言及されていないtriisため、ユーザーに実行権限が必要ではないように見えます。EXECUTEしかし、SHOW GRANTS-command が実稼働サーバーと開発サーバー (特にALL PRIVILEGES両方のサーバー) で驚くほど似た結果を返すのを見て、なぜ PHP コードが開発側でのみ機能するのか少し混乱しています。

これが本番環境でのアクセス許可の問題であることが判明した場合、GRANT CREATE ROUTINE, EXECUTE ON * TO triis@'localhost'これおよび将来のストアド プロシージャの実行権限を付与するのに役立つものはありますか?

御時間ありがとうございます！:)

4

1 に答える 1

2

これは当初考えていたパーミッションの問題ではなく、UPDATEストアド プロシージャ ( ) 内で実行されている -statementでエラーが発生したためSPです。

このエラーは、(更新中の) テーブル名の大文字と小文字の区別と、開発環境と運用環境での大文字と小文字の不一致が原因でした。ストアド プロシージャは、 phpMyAdminで実行したときにエラーを直接報告しませんでした。さらに調査するために、mySQL シェルの運用サーバーでストアド プロシージャを実行するリソースがありませんでした。PHP で を実行しSPて診断することは役に立たず、SP両方の環境で s を実行するための完全な権限を持っているように見えますが、それでも開発側でしか結果を取得できず、困惑しました。

今日の教訓:バッククォートを入力するのは面倒ですが (少なくともアイスランド語のキーボードでは)、すぐにバッククォートを含めることをお勧めします。もう 1 つのオプションは、テーブル名またはプロシージャでキャメル ケースを使用しないことです。phpMyAdmin を使用して mySQL スクリプトを生成すると、ティックが追加され、大文字と小文字が区別されます。生成されたスクリプトを 1 つの環境でのみ実行すると、まだ開発中の (生成されたバッチの一部ではない) スクリプトで問題が発生する可能性があります。

于 2012-11-12T16:06:36.880 に答える