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