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

Our new SQL Server Forums are live! Come on over! We've restricted the ability to create new threads on these forums.

SQL Server Forums
Profile | Active Topics | Members | Search | Forum FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 Site Related Forums
 Article Discussion
 Article: What will C# Look Like in SQL Server?
 Reply to Topic
 Printer Friendly
Previous Page
Author Previous Topic Topic Next Topic
Page: of 2

Merkin
Funky Drop Bear Fearing SQL Dude!

Australia
4970 Posts

Posted - 04/22/2002 :  19:21:01  Show Profile  Visit Merkin's Homepage  Reply with Quote
It's always easier to flame than introduce something useful into the conversation.


See ?

Damian
Go to Top of Page

Nazim
A custom title

United Arab Emirates
1408 Posts

Posted - 04/25/2002 :  01:33:46  Show Profile  Reply with Quote
Found this Article. though the Author doesnt dvelves into advance features but still no harm having a look http://aspalliance.com/stevesmith/articles/ViewArticle.aspx?id=27

--------------------------------------------------------------
Go to Top of Page

Douglas
Starting Member

1 Posts

Posted - 04/28/2002 :  05:40:59  Show Profile  Reply with Quote
quote:

quote:

Q) How do you fix TSQL Error handling (lack of)
A) Add another language!



I would assume if they really want parity between T-SQL and the .NET languages they'll have T-SQL compile into MSIL. That means they should be able to add cool new features to T-SQL very easily. There's no reason it couldn't have a try ... catch block also!

Case sensitivity is really my only complaint with C# so far. It's just like stepping back a decade. However since all variables are required to be defined the errors usually jump out at you pretty quick.



===============================================
Creating tomorrow's legacy systems today.
One crisis at a time.



Graz I do agree, if TSQL is a .net language, (as there are rumors that it will be), It will have full access to the framework classes.
IOW have access to error handleing. And will be a compiled language.

It is interesting to note that with Windows Scripting Host will have a framework version and All framework languages will become scripting languages. No more VB Script or VBA, it will be full languages from the framework, (who knows maybe even TSQL).

But it is interesting to see where MS is going with this. The entire system will be programmable with full languages. from Apps to the system. If MS takes it that far.

Maybe we will actually see Cairo in our lifetimes;)

Douglas

Go to Top of Page

Arnold Fribble
Yak-finder General

United Kingdom
1961 Posts

Posted - 04/28/2002 :  06:14:57  Show Profile  Reply with Quote
I thought XP = chi rho = Cairo.


Go to Top of Page

chadmat
The Chadinator

USA
1974 Posts

Posted - 04/29/2002 :  16:50:12  Show Profile  Visit chadmat's Homepage  Reply with Quote
Actually,

Cairo was a pre NT 4.0 product that didn't make it.

XP was Whistler

-Chad

Go to Top of Page

rrb
SQLTeam Poet Laureate

Australia
1479 Posts

Posted - 04/29/2002 :  18:42:34  Show Profile  Reply with Quote
's all greek to me. Or was that Egyptian? I guess I should be careful here, or I'll be hoisted on my own pyramid...

Edited by - rrb on 04/29/2002 18:47:14
Go to Top of Page

jasper_smith
SQL Server MVP & SQLTeam MVY

United Kingdom
846 Posts

Posted - 07/01/2002 :  15:43:48  Show Profile  Visit jasper_smith's Homepage  Reply with Quote
Just to add a bit more fuel to the fire......
I saw a pre beta demo at the UK SQL Server User Group meeting and CLR integration is going to be much more like xp's currently are i.e. you will create your assembly (dll) containing your classes,methods,properties etc and then "introduce" it to SQL via the CREATE ASSEMBLY,CREATE FUNCTION,CREATE TYPE (for user defined data types - proper ones not what we think of them as now) keywords and then call the methods from within TSQL. It should be able to handle most (if not all) the available .NET languages and within your .NET assembly you can do pretty much what you want (grab a stock quote from the internet for instance - not recomended) including data manipulation - in fact since the ADO.NET group report to the SQL Server group the data access optomisations look like being a great feature with a simple additional paramter to specify if its running in process (and thus avoiding the TDS translation cost) or not. Currently the cost entry point for .NET functions is higher than TSQL and the aim is to bring it down to the same level - however .NET functions performing complex mathematical functions will scale much better than TSQL.

Error handling - whilst not as advanced as Try..Catch available in .NET will be much improved over the current state of affairs.

DTS and Analysis Services sound like they're getting a good overhaul too so look for improvements in that area. The demo I saw actually ran like a bit of a dog (although it was a lap top with 3 operating systems running at the same time because it was also demoing Microsoft Operations Manager) but perfectly happily using SQL 2000 Query Analyser and SQL2000 with upgraded metadata.

They are not going to bastardise TSQL - it will remain pretty much the same and the product will come with a large list of do's and don'ts for .NET interoperability so those developers don't get carried away trying to do things in cobol.net that would be better off left in TSQL. There will also be new MOC courses for Yukon including possibly a .NET for DBA's type course to stop us all having heart attacks at the though of all this managed code running in process with SQL.
The door is still open at sqlwish@microsoft.com for new ideas for the product and every email is read but its almost closed so get you ideas's in.

To be honest it was quite a lot to take in, in a short space of time and everyone was pretty much overwhelmed so I've probably forgotten more than I remember. Overall impressions are that this CLR integration will be very useful in specific area's but not the leapforward some of the speculation suggests, TSQL will be improved however its not becoming a hybrid C# and will still be the primary data access and manipulation language (so don't throw those TSQL books in the bin just yet!)and we're going to get some REALLY cool tools that I don't think I'm allowed to mention yet .

Yukon is still a long way off but already I think we've got a lot to look forward too!!



HTH
Jasper Smith
Go to Top of Page

AjarnMark
SQL Slashing Gunting Master

USA
3246 Posts

Posted - 07/01/2002 :  19:27:08  Show Profile  Visit AjarnMark's Homepage  Reply with Quote
We had MS on site last week to talk about SQL 2000, but I grilled them as much as I could about Yukon. Unfortunately that wasn't very much because the people here either didn't really know, or were really good at feigning ignorance. The one thing they kept hitting on were a new development environment (IDE) with a well integrated sproc debugger much more on par with the VB or .Net debugger.

Graz, sorry I didn't get an invitation to you in time. This got scheduled and then changed at the last minute.

Go to Top of Page

jasper_smith
SQL Server MVP & SQLTeam MVY

United Kingdom
846 Posts

Posted - 07/01/2002 :  20:14:12  Show Profile  Visit jasper_smith's Homepage  Reply with Quote
quote:

The one thing they kept hitting on were a new development environment (IDE) with a well integrated sproc debugger much more on par with the VB or .Net debugger



That's the bit I don't think I'm allowed to mention - although we didn't sign any NDA - however if you think of what an improvement SQL2000 QA was over SQL7 and you look at the VS.NET tools you can "speculate" as to what it will look like

HTH
Jasper Smith
Go to Top of Page

richmondata
Starting Member

3 Posts

Posted - 11/05/2003 :  20:13:51  Show Profile  Reply with Quote
A hundred years or so ago, I worked on mainframe DB2. They separated control of flow language from DML/DDL. Essentially, the control-of-flow language (PL/1, etc) did its thing its way while the DML statements conformed to the SQL syntax of the time. It seems that would avoid the bastardization of c# that concerns a lot of the posters. No doubt it would also create problems of its own. Any indications/updates as to what MS is doing to address the concerns regarding temptations for having a SQL "dialect" of c# (for lack of a better term)?

Thanks.
Go to Top of Page
Page: of 2 Previous Topic Topic Next Topic  
Previous Page
 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.08 seconds. Powered By: Snitz Forums 2000