[dba-VB] SPAM-LOW: Re: How do you run SQL Server processes

jwcolby jwcolby at colbyconsulting.com
Wed Nov 4 15:11:58 CST 2009


Robert,

I don't really want to get in an argument about this.  I asked a serious question and got a somewhat 
brusque "answer" that isn't an answer at all.  OTOH it is (so far) the ONLY answer I have received 
so that is not particularly encouraging.

8(

TSQL, at least as written from inside of SSMS is about like writing GBasic code back in 1982.  Well, 
maybe a tiny step up but not much.

You are right, I probably just don't know how, but in what I will call "a real language" I can set 
breakpoints, I can see a call stack, I have watch statements,  I have... simple very basic DEBUG 
capabilities that I have never ever ANYWHERE seen mentioned for TSQL (in SSMS).  I can have forms 
with controls displaying data, buttons that cause things to happen.  I can FTP files, monitor 
directories for activities.

Believe me, if this exists in SSMS I will jump on that!  Just don't tell me to go spend thousands to 
buy a tool that will do some of what C# can already do for me.

Modern languages, and the .Net environment in particular have capabilities that (AFAICT) TSQL can 
not even dream of.  TSQL dreams of manipulating data, C# dreams of manipulating ... the world.

Robert I am not "fighting learning it", I am light years beyond where I was two years ago, and I 
learn more TSQL and SQL Server every day.  However from what I have seen so far, TSQL will NEVER be 
what I need for the supervisor.  And answers like you just provided aren't really much help.

I am a consultant.  I am a programmer, not a DBA, or a SQL Server administrator, or a SQL Server 
jock at a company somewhere.  I need C# for automating my business, which is NOT being a DBA (I 
already said that I think).  I will write C# applications for clients that use SQL Server, and 
others that do not use SQL Server.  SQL Server is used by exactly ONE of my clients, so I cannot 
spend the time to do whatever it is that you envision SQL Server doing because I cannot amortize the 
learning over other clients.

Now... if you want to answer my question, I am all ears.  The first thing to answer (If I am to do 
all this in TSQL) is how do I get a modern tool with all of the debug capabilities to write TSQL code.

Let's take a concrete, real world example.  I have a set of virtual machines which run a third party 
application.  I place files into an "inbox" directory, and I wait for files to pop out of the 
running application into the "outbox" directory.  Just an aside, the files placed into the inbox are 
created by a set of about 5 stored procedures, which can operate on any of dozens of databases in my 
server.

It is the case that the third party application occasionally hangs.  If it does I need to rename a 
file in a specific directory to cause that application to restart processing that file.

It is my intention to use C# to execute the SPs to create the files, move the files into the VM, 
then monitor files dropped into the inbox, and files popping out into the outbox.  Look for "no new 
files in X minutes" and if that condition exists, rename the file.  Log files dropped into the 
in-box, files popping out into the out-box, and the time it took for the files to process through 
the application.  Log any "hangs" restarted.  Supervisor stuff.

Explain to me how (and more importantly WHY) I would use TSQL to do that?  Other than a "when TSQL 
is all you have" (which is NOT true for me) mentality.

A SMALL part of my business is to perform some moderately complex processes using SQL Server and SPs 
as a tool.  I envision C# as a supervisor, not a "middle layer".  I envision an application (written 
in C#) that runs on my desktop which starts, then monitors SQL Server processes, displays errors, 
restarts processes if necessary, creates databases, tables etc, backs them up and detaches them when 
done, logging everything that happens, showing it all to me me in real time in a Windows 
application.  Possibly even automatically generating invoices for the work done and emailing them to 
the client.

Explain to me one more time (with feeling) how (and more importantly WHY) I would use TSQL to do all 
of that stuff?

John W. Colby
www.ColbyConsulting.com


Robert Stewart wrote:
> Sorry, but using C# to do what you would and could do simply using 
> SQL Server is adding a middle layer you do not need. You can do 
> exactly the same thing using SQL Server and stored procedures and 
> writing to a log table about what the process is doing and keeping 
> track of it that way. And, not have to use a middle layer language 
> like C# to do it.
> 
> I am not sure why writing T-SQL code is not like real programming to 
> you.  But, it is.  And, if you are going to continue using SQL 
> Server, you need to learn what it can do for you instead of always 
> fighting learning it.
> 
> This is coming from someone that does T-SQL, C#, VB.Net and Access 
> VBA.  So, I think I have a fair perspective of how they all work.




More information about the dba-VB mailing list