jwcolby
jwcolby at colbyconsulting.com
Wed Nov 4 17:01:33 CST 2009
Gustav, >as I'll never be more than a decent low-level DBA. Likewise. And that is precisely my problem. I think when you spend all day in TSQL it is easy to lose sight of just how crude the environment is. I have finally gotten to the point where I can write a SP, debug it, get it functioning etc but it is just hard. Not that C# isn't hard, but C# is a general purpose language where the effort spent is useful for other things. And with the debugging tools in .Net, debugging things is really pretty easy, very similar to many other environments. I can go weeks without doing SQL development and when I go back it is a PITA to pick back up. What it does, it does well, what it doesn't do... it doesn't do quite spectacularly. > I guess Robert is a very skilled DBA and can write T-SQL with his left foot It certainly seems so. But with my current understanding of SQL Server and TSQL I cannot imagine doing the big picture of my work strictly with TSQL. With my current understanding, TSQL will only ever be a hand full of processes, 30% of the whole job. Don't get me wrong, there is no alternative to the power of SQL Server, but in the end it is just a place to store data and some tools for getting it out and back in to tables. Everything else is out in the real world. John W. Colby www.ColbyConsulting.com Gustav Brock wrote: > Hi John > > I have no answer to you but if it can bring you some relief, I feel much the same. The database is for storing data, a business layer and/or a front end is for the logic and interface. > That said, nothing is perfect, and in the real world you will have to write some T-SQL or similar but I try to keep it at minimum, first because of the trouble of maintenance (for example, no version control I know of), second because I feel old when I write "GBasic style" code. And I'm not in a big corporation where I can get every expensive tool I can point at, and tools for SQL Server seem all to be enterprise-priced. So, writing views and T-SQL is because I have to, writing C# (and VBA for that matter) is because I like to. > > I guess Robert is a very skilled DBA and can write T-SQL with his left foot and that's very good - then we know where to ask for advice as I'll never be more than a decent low-level DBA. > > /gustav > > >>>> jwcolby at colbyconsulting.com 04-11-2009 22:11 >>> > 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 > > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > >