Gustav Brock
Gustav at cactus.dk
Wed Nov 4 16:21:22 CST 2009
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