Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 Site Related Forums
 Poll Discussion
 Poll: What language will you use in Yukon

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
Nooooooooooooooooooooo

Make the hurting go away

Damian
Go to Top of Page

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
Go to Top of Page

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.

Go to Top of Page

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
Go to Top of Page

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".



Go to Top of Page

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...
Go to Top of Page

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!!!!!

DavidM

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

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

Go to Top of Page

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.
Go to Top of Page

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...
Go to Top of Page

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
Go to Top of Page

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.

Go to Top of Page

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?

Go to Top of Page

JustinBigelow
SQL Gigolo

1157 Posts

Posted - 2002-02-07 : 16:00:51
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 - 2002-02-18 : 03:49:23
Well, i rather use lisp or simon' basic in Yukon...

Go to Top of Page

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
Go to Top of Page

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.

Go to Top of Page

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.
Go to Top of Page
   

- Advertisement -