January 17, 2014 at 4:07 pm
Hands down, it would be T-SQL for me with calls from there to PoSh and only if needed. T-SQL doesn't seem to change as much as all the other stuff and it's all available in the server. You don't have to look for source code, find someone with a compiler that still works for the version of the code and all its possible 1st and 3rd party add-ins, etc, etc.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2014 at 6:57 pm
You're right it's not about me. Of course. Sort of! I'm all in favor of doing the best thing for the company, but sometimes that isn't obvious. Imagine you're still running VB6 code. Do you build that next mini app using VB6 because it's what you do, or do you try .net because it has to happen someday, even if it takes longer to do?
I'm not advocating deciding solo but its our job to advocate for some solution.
January 20, 2014 at 5:38 am
Andy Warren (1/19/2014)
You're right it's not about me. Of course. Sort of! I'm all in favor of doing the best thing for the company, but sometimes that isn't obvious. Imagine you're still running VB6 code. Do you build that next mini app using VB6 because it's what you do, or do you try .net because it has to happen someday, even if it takes longer to do?I'm not advocating deciding solo but its our job to advocate for some solution.
Still sounds like you are doing it for the benefit of the company...whether they like it or not 😉
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 20, 2014 at 7:37 am
Back in the 90's, I developed a data warehouse (my first) that partitioned data by state into seperate tables and by period year into seperate databases. For maintenance operations, I wrote a VB6 application to execute T-SQL commands across databases and tables as needed. Rather than embedding SQL within the application, the way I did it was to contain all SQL code within .sql scripts which were themselves contained within a hierarchy of folders. The sql scripts contained tags (ex: use {database}; update history_{periodyear} ...) for which the application would perform substitution at execution time.
The form load event of the application would dynamically build it's menu hierarchy and items based on the folder structure and scripts, so that the name of the script became the actual name of the meny item. Whenever a T-SQL batch process was needed, I simply created a new .sql file under the appropriate folder, which required no modification to the application code.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 20, 2014 at 8:56 am
Gary, that's true if you don't engage them in the decision. A lot of times they don't care, it's too small."Go capture db space usage once a day". If you use any tech the company currently uses, do they care (minus any guidance to use or not use x)? Does your boss want o debate the merits of powershell vs SSIS vs x for a tiny effort? If not, then we pick, and a philopshy helps do that.
January 20, 2014 at 9:03 am
The greatest factor in our decision process was the quantity of servers. For a smaller number, 10-50, single threaded options, such as SSIS, completed in a timely manner. We now have 4,500 servers, and even with each store completing in 1 second, it would be more than one hour to complete. This is acceptable for our internal system checks, but does not enable business users to answer questions in a timely manner.
January 20, 2014 at 9:39 am
Eric, that makes sense. What I did recently was write multi-threaded code and drop in a script task - worlds of difference. Using or abusing the tools? Depends!
January 21, 2014 at 8:42 am
Being mainly a SQL person of course I tend to stick with T-SQL (or SSIS when needed), but also not too worried about using C# CLRs when needed. Having originated from programming in C and C++, this might scare me a lot less than some that have not maybe.
Also used PowerShell for a few things, but it seems clumsy to me still (which is mostly just a lack of experience indicator in my experience with other tools!).
But, if I use C# in CLRs, I tend to get one of our C# developers involved in it, since they are 100x better at it than I am. =)
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply