[dba-VB] How do you run SQL Server processes

jwcolby jwcolby at colbyconsulting.com
Thu Nov 5 11:32:51 CST 2009


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,




More information about the dba-VB mailing list