最近、ストアドプロシージャのデバッグに関するレッスンをまとめました。 それは私のストアドプロシージャの解凍コースの一部です。 ストアドプロシージャをデバッグすると、コードを1行ずつ実行して、ロジックの問題を簡単にトラブルシューティングできます。
ストアドプロシージャのデバッグに慣れていない場合は、この入門ビデオを見てください。
あなたはこれについての詳細を学ぶことができますこのビデオ、それはトランスクリプトは次の
あなたはストアドプロシージャをデバッグする方法 大幅な割引でそれを取得するには、クーポンコードBLOGPOST-201を使用してください。
ストアドプロシージャのデバッグ
このセクションでは、ストアドプロシージャのデバッグについて説明します。 私たちはデバッグし、手順を開始する方法の仕組みを介して作業に入る前に、私はちょうど背景とデバッグが本当に何であるかについて話すだろう
コンピュータが最初に発明された初期の頃、彼らは機械的であり、彼らがacomputerで持っていた最初の問題の一つは、実際にリレーに立ち往生し、therelayが機能を停止
それが最初のコンピュータのバグとなった。 それは、彼らが実際に
を見つけた場所であるため、”デバッグ”という用語がどこから来ているのかです。 ここにその最初のバグの写真があり、それはWikipediaの記事からのものなので、それはトリビアです。
あなたがコンピュータ上で知っているように、専門用語がたくさんあります、あなたは常にそれがどこから来ているのだろうか。 これは実際には実際のライブバグから来ており、そこにはスコッチテープの下にあります。
なぜストアドプロシージャをデバッグするのか疑問に思うかもしれません。 その理由は、SQLがより複雑になるにつれて、エラーがどこにあるのかを理解することが難しくなるからです。
ストアドプロシージャがますます多くのステートメントを取得するにつれて、タイプミスや論理エラーがどこにあるかを理解するのは少し難しくなり、文を実行する方法が必要になり、プログラムを実行しているときに顕微鏡を取り出し、比喩的に言えば、プログラムがどのように動作しているかを確認し、特定の時点でプログラムが動作しているかどうかを判断し、そうでない場合は、より良い動作を得ることができます。私たちはそのすべての問題を修正することができますので、何が起こっているかの理解 見てる
だから、ストアドプロシージャをデバッグすると、盲目の試行錯誤を使用するよりもはるかに優れたトラブルシューティングが可能になります。 だから、私たちはセッションを通して私たちの仕事に入るつもりだいくつかの本当に便利なデバッグの概念があります。
そのうちの1つはStep Intoと呼ばれるもので、ストアドプロシージャを実行している場所であり、コードを別のプロセスにステップインします。
ストアドプロシージャをスキップできるステップオーバーのようなものがあるので、興味のないストアドプロシージャに行単位で実行する必要はあ
ブレークポイントと呼ばれるものを設定することができ、ストアドプロシージャでその行が見つかった場合にコードを自動的に停止させることができます。
検査できるローカル変数もあります。 ストアドプロシージャが実行されているときに、実際にourvariablesの値を見ることができます。
これらはすべて、ストアドプロシージャのトラブルシューティングに役立つ非常に便利な概念です。
だから次のレッスンでは、実際にこれらの概念を使用して生き生きとさせるつもりです。
ストアドプロシージャのデバッグ方法の詳細を知りたい場合は、ストアドプロシージャのアンパックコースを受講してみてください。 大幅な割引でそれを取得するには、クーポンコードBLOGPOST-201を使用してください。
