| Author |
Topic |
|
graz
Chief SQLTeam Crack Dealer
4149 Posts |
 Posted - 2002-02-04 : 00:53:32
|
| This thread goes with this poll (http://www.sqlteam.com/PollResults.asp?PollID=134).You can see more in this InfoWorld article (http://www.infoworld.com/articles/hn/xml/01/06/18/010618hnsql.xml)Or these articles (http://www.google.com/search?q=yukon+CLR+sql+server&hl=en&lr=lang_en&output=search)===============================================Creating tomorrow's legacy systems today.One crisis at a time. |
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2002-02-04 : 01:00:44
|
| NoooooooooooooooooooooMake the hurting go awayDamian |
 |
|
|
Nazim
A custom title
1408 Posts |
Posted - 2002-02-04 : 09:43:33
|
| i will go for C# . coz i miss Arrays in T-Sql and feel C# will be handy for Sql-Dmo too.--------------------------------------------------------------Dont Tell God how big your Problem is , Tell the Problem how Big your God is |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-02-04 : 10:16:27
|
quote:
i will go for C# . coz i miss Arrays in T-Sql and feel C# will be handy for Sql-Dmo too.
Good, we'll let you answer all of the "I'm trying to use a cursor in C# and the performance really sucks!" questions THAT WILL be asked here on SQL Team  I'm sticking with T-SQL. It ain't broke, and .Net ain't fixing it!BTW, what do you need arrays for that you can't use CSV or tables for? If you really need array support, pick up Ken Henderson's new book:The Guru's Guide to SQL Server Stored Procedures, XML and HTML(my first endorsement of Ken's new book!)...he has written extended stored procedures that provide array functions, and the code to create UDFs out of them if you use SQL 2000. |
|
|
|
Nazim
A custom title
1408 Posts |
Posted - 2002-02-04 : 10:28:38
|
No Chance Rob coz All the Cursor questions will be taken care by nr and Perfomance one's by Ilya or Chad .i think you should ask Graz to change your title to "The Guru's Guide to SQL Server Stored Procedures, XML and HTML-Ken's Pimp"--------------------------------------------------------------Dont Tell God how big your Problem is , Tell the Problem how Big your God is |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-02-04 : 10:51:35
|
quote:
No Chance Rob coz All the Cursor questions will be taken care by nr
Oh yeah, like HE'S gonna want to learn C#!  Don't count on it! The answer will be "don't use cursors". I'd like to see how SQL.Net will work without 'em (seriously, I would).I suggested my new title of "Ken Henderson's Bitch" to graz but he hasn't warmed to it yet. I don't know if Ken would like it much either, except that it's much better than "Ken Henderson's Pimp". |
|
|
|
AjarnMark
SQL Slashing Gunting Master
3246 Posts |
Posted - 2002-02-04 : 18:38:33
|
| We get enough cursor questions with T-SQL. I fear to see what will come with .Net languages. (shiver)Although, I must say that Yak# sounds promising.--------------------------------There's a new General in town... |
|
|
|
byrmol
Shed Building SQL Farmer
1591 Posts |
Posted - 2002-02-04 : 19:04:54
|
| I am with you Rob,If you cannot do it in TSQL you are in the wrong Tier!!!!!DavidMTomorrow is the same day as Today was the day before. |
|
|
|
Teroman
Posting Yak Master
115 Posts |
Posted - 2002-02-05 : 11:46:08
|
| Does anyone know where there are examples of how using another language would work, cos I just dont seem to get it. The way i see it the SQL language is set based, where the others are procedural (may be the wrong word).I mean, ive done my share of VB and JScript, which are suggested here, and neither of it makes me think, ah yes, this could be used for joining.Or is it simply that there will be alternative syntax for things like if/loop/case for program control, and the actual core SQL things will stay the same?Or am i being exremely dense (not unlikely)col |
|
|
|
graz
Chief SQLTeam Crack Dealer
4149 Posts |
Posted - 2002-02-05 : 12:40:04
|
| Teroman,I think since Yukon is still 12 months away there aren't any examples of how things would be done yet. They did show us a very limited demo at SQLPASS in Denver.My guess: The SQL language itself won't change. The constructs around SQL(if/loop/case/etc.) will change to whatever syntax of language you use. You'll probably find better declarations of functions/subroutines WITHIN stored procs -- or maybe not :)Just my humble guess :)===============================================Creating tomorrow's legacy systems today.One crisis at a time. |
|
|
|
AjarnMark
SQL Slashing Gunting Master
3246 Posts |
Posted - 2002-02-05 : 12:55:57
|
| I would suspect you're both right, because, as Teromoan pointed out, you still need a way to join tables. My primary concern; however, is that with other languages programmers who are used to doing one-record-at-a-time processing will be tempted to use that same mindset when they write sprocs because the language looks the same. So I fear that there will be fewer prompts that "Hey, this is a different language, and there's a different approach to productivity". But maybe that was illusory anyway.--------------------------------There's a new General in town... |
|
|
|
nlocklin
Yak Posting Veteran
69 Posts |
Posted - 2002-02-05 : 15:21:07
|
I see you included COBOL.NET, but you forgot Fortran. Unfortunately with over 4,000 programs written in Fortran where I'm working that they're starting to migrate, I will probably have a Fortran.NET program or two running on my servers.  --"I'm always doing that. I'm always messing up some mundane detail."Edited by - nlocklin on 02/05/2002 16:22:55 |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-02-05 : 18:25:13
|
| I totally agree with Mark (that's a solid 23 in a row!); procedural languages like C#, VB.Net, etc. in SQL procedures will cause grief, confusion, and lots of extra overtime for consultants...hmmmmm, maybe it's NOT such a bad idea! Seriously, while I don't welcome .Net in SQL that much, I can't help but think that all those really cool things, like regular expressions, user-defined functions, string, math, and system functions available through these languages, would really make T-SQL unbelieveably powerful. We get a ton of requests for how to parse strings, or combine them, or perform wicked pattern matching, that are extremely hard to do in T-SQL, but are a piece of cake for regular expressions in pretty much every language: C++, Java(Script), VB, Perl. Someone had a request a while back on how to stream data (audio, video, whatever) that was stored in a database. I don't know if that's the best way to store it, but MAN, that would be really cool! And probably pretty easy with .Net.That's where I'm focusing my attention: sticking with what SQL Server does well right now, and adding new, amazing stuff. We will most likely have just as many people writing (bad) procedural code to do set-based work; they'll just be putting it into SQL stored procedures instead of ASP/VB/C++ projects like they do now. |
|
|
|
izaltsman
A custom title
1139 Posts |
Posted - 2002-02-06 : 11:02:44
|
Ugh! I'm not too keen on the idea of allowing all those .NET languages touch the database. Just look at it from the system maintenance perspective. I am sure a number of organizations will forget to set internal standards to limit what languages to use for database access... And then there will be some adventurous developer, who decides to write a bunch of mission-critical stored procedures in some obscure language that no one has ever heard of... If that guy ever leaves the company, who is going to troubleshoot those procs and make changes to them when necessary?  |
|
|
|
JustinBigelow
SQL Gigolo
1157 Posts |
|
|
hande
Starting Member
8 Posts |
Posted - 2002-02-18 : 03:49:23
|
| Well, i rather use lisp or simon' basic in Yukon... |
|
|
|
HumanCompiler
Starting Member
4 Posts |
Posted - 2002-03-05 : 16:56:57
|
I know this is an old topic, but I just got here so I thought I'd chime in anywho! I'd like to try VB.NET in my SPs just to see what it's like, see if there are any advantages, etc...but I'd probably be more likely just to use T-SQL still.Someone earlier talked about needing arrays...I'm pretty sure at some MS conference I was at (PDC or TechEd, don't remember) they mentioned that Yukon would have a new field type of "array"...has anyone heard any news on this lately? Is this still going to happen? Am I behind the times? What's up?  -Erik |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-03-05 : 17:28:45
|
| I'm getting the impression from the Jim Gray interview:http://www.fawcette.com/interviews/gray/page2.asp...that any datatype that's available through the CLR/C#/VB.Net etc. will be allowed in a SQL Server database (check out the "impedance mismatch" paragraph). So arrays would almost certainly be supported.I have to admit though, I just can't see how that's going to work, let alone work well. I guess we'll see. |
|
|
|
graz
Chief SQLTeam Crack Dealer
4149 Posts |
Posted - 2002-03-06 : 08:33:17
|
I think one of the things they are going to work on is unstructured data. If Yukon really does become the storage engine for Exchange and the "Blackcomb" file system they will have to handle unstructured data very well. An array column would make a good recipient list :)That same paragraph also talks about XPath for trees. Maybe they'll give us a native way navigate a tree  I'd be OK with that!===============================================Creating tomorrow's legacy systems today.One crisis at a time. |
|
|
|
|
Poll: What language will you use in Yukon