يدعم خادم Microsoft SQL Server مفهوم الاستعلامات الديناميكية Dynamic Queries، وهي استعلامات يتم تولديها وقت تنفيذ الاجراء Stored Procedure. فمثلا، الاجراء التالي: 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). كن ديناميكي تسهل عليك الحياة أكثر، ولكن تذكر فللديناميكية حدود! -- تركي