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

Shamil Salakhetdinov shamil at smsconsulting.spb.ru
Thu Nov 5 07:01:18 CST 2009


Hi John,

I just posted links as you asked about this feature but I must note I have
used T-SQL debugging just once when I used T-SQL cursors (and that was my
mistake I suppose) - IOW I doubt that cursors/T-SQL debugging will be ever
needed for you as you plan to use C# to drive your T-SQL's SPs...

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 2:09 AM
To: Discussion concerning Visual Basic and related programming issues.
Subject: Re: [dba-VB] SPAM-LOW: Re: How do you run SQL Server processes

Thanks for that.  I guess I will need to install my professional edition
license to go there. 
Worthwhile though I am guessing.

John W. Colby
www.ColbyConsulting.com


Shamil Salakhetdinov wrote:
> Hi John,
> 
> <<<
> 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.
> 
> Overview of T-SQL and CLR debugging in SQL Server 2005
> http://blogs.msdn.com/sqlclr/archive/2006/06/29/651644.aspx 
> 
> How to: Enable SQL Server 2005 Debugging
> http://msdn.microsoft.com/en-us/library/s0fk6z6e(VS.80).aspx
> 
> HTH,
> 
> --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 12:12 AM
> To: Discussion concerning Visual Basic and related programming issues.
> Subject: Re: [dba-VB] SPAM-LOW: Re: How do you run SQL Server processes
> 
> 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.
> 
> _______________________________________________
> dba-VB mailing list
> dba-VB at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-vb
> http://www.databaseadvisors.com
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
signature
> database 4574 (20091104) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.esetnod32.ru
> 
> 
>  
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
signature
> database 4574 (20091104) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.esetnod32.ru
>  
> 
> _______________________________________________
> dba-VB mailing list
> dba-VB at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-vb
> http://www.databaseadvisors.com
> 
> 
_______________________________________________
dba-VB mailing list
dba-VB at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-vb
http://www.databaseadvisors.com


__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4575 (20091105) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru






More information about the dba-VB mailing list