SQL Server Forums
Profile | Register | Active Topics | Members | Search | Forum FAQ
 
Register Now and get your question answered!
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 Site Related Forums
 Poll Discussion
 Poll: What language will you use in Yukon
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

graz
Chief SQLTeam Crack Dealer

USA
4138 Posts

Posted - 02/04/2002 :  00:53:32  Show Profile  Visit graz's Homepage  Reply with Quote
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!

Australia
4970 Posts

Posted - 02/04/2002 :  01:00:44  Show Profile  Visit Merkin's Homepage  Reply with Quote
Nooooooooooooooooooooo

Make the hurting go away

Damian
Go to Top of Page

Nazim
A custom title

United Arab Emirates
1408 Posts

Posted - 02/04/2002 :  09:43:33  Show Profile  Reply with Quote
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
Go to Top of Page

robvolk
Most Valuable Yak

USA
15683 Posts

Posted - 02/04/2002 :  10:16:27  Show Profile  Visit robvolk's Homepage  Reply with Quote
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.

Go to Top of Page

Nazim
A custom title

United Arab Emirates
1408 Posts

Posted - 02/04/2002 :  10:28:38  Show Profile  Reply with Quote
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
Go to Top of Page

robvolk
Most Valuable Yak

USA
15683 Posts

Posted - 02/04/2002 :  10:51:35  Show Profile  Visit robvolk's Homepage  Reply with Quote
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".



Go to Top of Page

AjarnMark
SQL Slashing Gunting Master

USA
3246 Posts

Posted - 02/04/2002 :  18:38:33  Show Profile  Visit AjarnMark's Homepage  Reply with Quote
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...
Go to Top of Page

byrmol
Shed Building SQL Farmer

Australia
1591 Posts

Posted - 02/04/2002 :  19:04:54  Show Profile  Reply with Quote
I am with you Rob,

If you cannot do it in TSQL you are in the wrong Tier!!!!!

DavidM

Tomorrow is the same day as Today was the day before.
Go to Top of Page

Teroman
Posting Yak Master

United Kingdom
115 Posts

Posted - 02/05/2002 :  11:46:08  Show Profile  Send Teroman an AOL message  Reply with Quote
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

Go to Top of Page

graz
Chief SQLTeam Crack Dealer

USA
4138 Posts

Posted - 02/05/2002 :  12:40:04  Show Profile  Visit graz's Homepage  Reply with Quote
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.
Go to Top of Page

AjarnMark
SQL Slashing Gunting Master

USA
3246 Posts

Posted - 02/05/2002 :  12:55:57  Show Profile  Visit AjarnMark's Homepage  Reply with Quote
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...
Go to Top of Page

nlocklin
Yak Posting Veteran

USA
69 Posts

Posted - 02/05/2002 :  15:21:07  Show Profile  Visit nlocklin's Homepage  Send nlocklin an AOL message  Send nlocklin an ICQ Message  Send nlocklin a Yahoo! Message  Reply with Quote
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
Go to Top of Page

robvolk
Most Valuable Yak

USA
15683 Posts

Posted - 02/05/2002 :  18:25:13  Show Profile  Visit robvolk's Homepage  Reply with Quote
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.

Go to Top of Page

izaltsman
A custom title

USA
1139 Posts

Posted - 02/06/2002 :  11:02:44  Show Profile  Send izaltsman an AOL message  Send izaltsman an ICQ Message  Reply with Quote
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?

Go to Top of Page

JustinBigelow
SQL Gigolo

USA
1157 Posts

Posted - 02/07/2002 :  16:00:51  Show Profile  Reply with Quote
The following interview is interesting. It deals with SQL Server and .Net integration (as well as other SQL Server stuff).

http://www.fawcette.com/interviews/gray/

Justin

Go to Top of Page

hande
Starting Member

8 Posts

Posted - 02/18/2002 :  03:49:23  Show Profile  Reply with Quote
Well, i rather use lisp or simon' basic in Yukon...

Go to Top of Page

HumanCompiler
Starting Member

USA
4 Posts

Posted - 03/05/2002 :  16:56:57  Show Profile  Visit HumanCompiler's Homepage  Send HumanCompiler an ICQ Message  Reply with Quote
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
Go to Top of Page

robvolk
Most Valuable Yak

USA
15683 Posts

Posted - 03/05/2002 :  17:28:45  Show Profile  Visit robvolk's Homepage  Reply with Quote
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.

Go to Top of Page

graz
Chief SQLTeam Crack Dealer

USA
4138 Posts

Posted - 03/06/2002 :  08:33:17  Show Profile  Visit graz's Homepage  Reply with Quote
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.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
SQL Server Forums © 2000-2009 SQLTeam Publishing, LLC Go To Top Of Page
This page was generated in 0.12 seconds. Powered By: Snitz Forums 2000