CREATE PROCEDURE GetRecords
AS
SET NOCOUNT ON
SELECT * FROM [Records]
RETURN
يقوم بالعودة بجميع السجلات في الجدول Records، لاحظ ان الاستعلام ستاتيكي (أي ثابت) لا يتغير ابدا، وحتى نجعله ديناميكي، بكل بساطة عرفه داخل متغير حرفي (من النوع varchar) ونفذه باستخدام Execute:
CREATE PROCEDURE GetRecords
AS
SET NOCOUNT ON
DECLARE @SQL varchar(1000)
SELECT @SQL = 'SELECT * FROM [Records]'
Execute (@SQL)
RETURN
الفوائد التي تجنيها من الاستعلامات الديناميكية لا تعد ولا تحصى، فما أروع ان تتحكم في جملة الاستعلام لحظة التنفيذ، هذا ابسط مثال يعتمد على الاستعلامات الديناميكية وفكرته انه إجراء سيعود بكافة السجلات من الجدول الذي ترسله مع الباراميتر:
ALTER PROCEDURE GetRecords
(
@tableName nvarchar(50)
)
AS
SET NOCOUNT ON
DECLARE @SQL varchar(1000)
SELECT @SQL = 'SELECT * FROM [' + @tableName + ' ] '
Execute (@SQL)
RETURN
يمكنك تنفيذ الاجراء -في أي وقت- مع ارسال الجدول الذي تود عرض سجلاته:
EXEC GetRecords ( ‘Records’ )
بالرغم من بساطة وتفاهة وسخافة المثال الذي عرضته، إلا انك قد تكون أبهرت بفكرة الاستعلامات الديناميكية وفتحت ابوابا لمئات الافكار التي كانت بمخيلتك، وقد تفكر بالاعتماد عليها دائما، ولكن عليك الحذر من قضيتين: الاولى ان تنفيذ الاستعلامات الديناميكية سيأخذ وقت اطول (بقليل) والسبب ان عملية التحقق Parsing ورسم مسار التنفيذ Executing Path لجمل الاستعلام ليست جاهزة (كحال الاستعلامات الستاتيكية). اما القضية الأخرى فهي في مسألة الأمان Security، لأنها تعطي فرصة كبيرة لتنفيذ جمل استعلام غير مصرح بها (خاصة ان كانت المتغيرات الديناميكية عمومية أكثر More Generic).
كن ديناميكي تسهل عليك الحياة أكثر، ولكن تذكر فللديناميكية حدود!
-- تركي