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,