Shamil Salakhetdinov
shamil at smsconsulting.spb.ru
Sat Nov 7 05:28:32 CST 2009
Hi John, Here is a .NET Reflection sample: using System; namespace NetReflectionSample { class Program { static void Main(string[] args) { string[] spRunnersNames = { "NetReflectionSample.SP1", "NetReflectionSample.SP2" }; foreach (string spRunnerName in spRunnersNames) { Type spRunnerType = Type.GetType(spRunnerName); StoredProcedureRunner runner = Activator.CreateInstance(spRunnerType) as StoredProcedureRunner; runner.Init(); runner.Run(); runner.CollectStats(); Console.WriteLine(); } } } public abstract class StoredProcedureRunner { public void Init() { Console.WriteLine("Initializing {0}...", this.GetType().ToString()); } public abstract void Run(); public void CollectStats() { Console.WriteLine("Collecting stats {0}...", this.GetType().ToString()); } } public class SP1 : StoredProcedureRunner { public override void Run() { Console.WriteLine("Running {0}...", this.GetType().ToString()); } } public class SP2 : StoredProcedureRunner { public override void Run() { Console.WriteLine("Running {0}...", this.GetType().ToString()); } } } Thank you. -- Shamil -----Original Message----- From: dba-vb-bounces at databaseadvisors.com [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Shamil Salakhetdinov Sent: Thursday, November 05, 2009 10:00 PM To: 'Discussion concerning Visual Basic and related programming issues.' Subject: Re: [dba-VB] How do you run SQL Server processes Hi John, <<< Do you remember reading my statement about "learning the minimum required to do the task at hand, right now"? >>> Yes, that is also what I mean: developing generic table-driven procedure for you currently could force you to learn more C#/.NET development stuff than when implementing "meta-process description" interpreter, which will consist of several C# code lines. But even the latter is not needed probably as you can hardcode your solutions for every custom task "shuffling" your parameterized wrappers classes/methods calling SPs, and instead of "Select stored procedure, select parameter,..." use "Create C# project, type C# code with calls to the wrapper classes/methods with Stored Procedures names and parameter names, types and values, then compile and run the custom solution". And it should be more suitable to debug/trace latter solution than "table-driven" or "meta-process description driven" ones... OK? (Am I still missing something here?) -- Shamil -----Original Message----- From: dba-vb-bounces at databaseadvisors.com [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Thursday, November 05, 2009 8:33 PM To: Discussion concerning Visual Basic and related programming issues. Subject: Re: [dba-VB] How do you run SQL Server processes Shamil, Listen to this... > Before you get comfortable with WF you can code you ProcessX, ProcessY, ... steps as "meta-process" text or xml files keeping fully qualified class names for your dedicated classes. And your "generic execution engine" will be just a simple code reading "meta-process" description, instantiating custom classes using .NET Reflection, calling their generic context/initialization methods, running SP by calling generic Run() method (parameters setting is inside your custom classes), then calling generic termination methods and iterating to the next step/finishing when "meta-process" file description ends. Now read this. Open form Select stored procedure, select parameter, select parameter. click save. Select stored procedure, select parameter, select parameter. click save. Continue till done. ;) Do you remember reading my statement about "learning the minimum required to do the task at hand, right now"? Read your solution again. John W. Colby www.ColbyConsulting.com Shamil Salakhetdinov wrote: > Hi John, > > If your "Process X", "Process Y",... calls to stored procedures do have > constant parameters' values then I do not see (I can be missing them) clear > reasons to use table-driven approach - I'd just have hardcoded ProcessX, > ProcessY, ... calling C# wrapper classes' methods to execute SPs. And the > latter wrapper classes can inherit from some generic base class(es) to keep > executing context, collect statistics etc... > > As I noted previously WF (Windows Workflow Foundation) could be a good > candidate for your subject area but WF has a steep learning curve so you > will not be able to effectively apply it right now but with small dedicated > classes, which you're writing right now (and delivering your custom > solutions right now) you'll be able to relatively easy migrate to WF based > solutions in the future. And if you will spend time working on generic > custom table-driven solution you'll probably have to throw it away later > when migrating to WF... > > Before you get comfortable with WF you can code you ProcessX, ProcessY, ... > steps as "meta-process" text or xml files keeping fully qualified class > names for your dedicated classes. And your "generic execution engine" will > be just a simple code reading "meta-process" description, instantiating > custom classes using .NET Reflection, calling their generic > context/initialization methods, running SP by calling generic Run() method > (parameters setting is inside your custom classes), then calling generic > termination methods and iterating to the next step/finishing when > "meta-process" file description ends. That could be it. > > Thank you. > > --Shamil > > -----Original Message----- > From: dba-vb-bounces at databaseadvisors.com > [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Thursday, November 05, 2009 7:34 PM > To: Discussion concerning Visual Basic and related programming issues. > Subject: Re: [dba-VB] How do you run SQL Server processes > > Shamil,