Hans VB's WebLog - For FREE!!!

About me (Hans Verbeeck). About my work (Partner Evangelist for Microsoft Belgium). Think big, start smal
Der deutsche Education Blog

March, 2004

  • Hans VB's WebLog - For FREE!!!

    SQL Server 2005 and Visual Studio 2005

    • 13 Comments

    Yesterday, the SQL Server team and the Visual Studio team made some significant announcements.

     

    The facts:

    The product name for SQL Server codename ‘Yukon’ is Microsoft SQL Server 2005

    • The SQL Server team is working hard to release Beta 2 in the coming months
    • There will be a Beta 3 release in the second half of 2004. Some early adopter customers will go live on this beta and will provide us with additional feedback before the product is shipped.
    • SQL Server 2005 is planned for release during the first half of 2005

     

    The official product name for Visual Studio codename ‘Whidbey’ is Microsoft Visual Studio 2005. It is also planned for release in the first half of 2005.

     

    The interpretation:

    These decisions are already stirring some dust (http://www.eweek.com/article2/0,1759,1546526,00.asp) and I expect more articles and blog entries to appear.

     

    If you asked people in the SQL team previously when Yukon was going to ship, you always got the answer ‘When it’s ready’. The information released today confirms the focus of the SQL team on quality and adds some detail on the schedule which will certainly be welcomed by our customers and partners.

     

    Yes, you might be thinking five years is a long time between SQL Server 2000 and SQL Server 2005. But it’s not like customers and partners have been waiting 5 years to get more functionality than was originally released with SQL Server 2000. I’ll name a couple technologies that have been made available to download since SQL Server 2000 was released:

    • Notification Services
    • SQLXML
    • Web Data Administrator
    • JDBC Drivers
    • SQL Server CE
    • SQLClient data provider in .NET Framework
    • SQL Server Reporting Services

     

    Very clearly, the developers at the SQL team have been really busy delivering the functionality needed by our customers today.

     

    Obviously SQL Server 2005 is the next big step. Big leaps are often scary but I definitely have a warm and fuzzy feeling about this one; especially because of the fact that more customers and ISV’s are involved earlier and deeper than ever before.

    A great example is for instance the number of applications from ISV’s that are tested on the daily builds of SQL Server Yukon. If a build breaks an application, the test teams are alerted and can investigate whether it’s by design or because of a bug.

     

    Many customers, MVP’s and partners are also experimenting themselves with the beta 1 bits they got through the beta program or from the PDC. The feedback these people are giving is taken very seriously. Even if you don’t have access to these bits, you can always send an email with your ideas to sqlwish@microsoft.com. Another channel the people in the product teams are monitoring closely is the newsgroups. These are the most important ones:

             Our most active SQL Server newsgroups,

            Microsoft.public.sqlserver.programming

            Microsoft.public.sqlserver.server

            Microsoft.public.sqlserver.dts

            Microsoft.public.sqlserver.olap

            Microsoft.public.sqlserver.setup

            Microsoft.public.sqlserver.replication

            Microsoft.public.sqlserver.msde

             34 world wide user groups,

            http://msdn.microsoft.com/usergroups/find.asp

             Also look here:

            http://www.microsoft.com/sql/community/default.mspx

     

    Assuring high quality in all areas including security, the abilities, productivity for developers and DBA’s, business intelligence… is not an easy task. But when you build a database that people run their businesses on, these are critical to success.

     

     

    This posting is provided "AS IS" with no warranties, and confers no rights.

  • Hans VB's WebLog - For FREE!!!

    Yukon: a story of love (and not so much love)

    • 4 Comments

    I'm heading for Helsinki at the moment to deliver another Workshop on SQL Server 2005 (formerly known as SQL Server Yukon) so I have some time to reflect on the previous deliveries of this workshop.

     

    The topics that I'm delivering myself are the developer related topics. One could categorize them as follows:

     

    • Yukon – CLR Integration
    • XML support in Yukon
    • T-SQL improvements
    • ADO .NET 2.0
    • Objectspaces
    • I’m obviously missing some topics here like the SQL Server Service Broker, Notification Services…

     

    The most loved topic is without any doubt the Yukon CLR.

    • People just see the productive boost this will bring for some types of procedural code they are writing to day in T-SQL.
    • Many people also see that this will enable a lot of scenarios that were previously impossible if one didn’t want to fall back on extended stored procs.
    • User defined aggregates are welcomed
    • User Defined types are something different. Many people don’t see where they could apply this after I tell them they shouldn’t use UDT’s to store for instance their customer objects. When thinking about a UDT, please think about new scalar types you might need. Classical example already is a location type with longitude/latitude and some methods to compare two points.
    • THE DANGER of offering the users to write .NET code and deploy it in SQL Server, lies in the fact that people are tempted to wrap any trivial SQL Statement in .NET code. That is NOT what it’s meant for! It’s not a rip (T-SQL) and replace (.NET code) story! It’s about using .NET code where it makes sense:
      • There are things that can only be done in .NET (UDT’s and User Defined Aggregates)
      • When you have more business logic in you procedure than raw data access
      • When using functions from the .NET Framework makes you more productive as well as your code more performing.

     

    The topic adored by some while invoking a big yawn from others: XML Integration

    • People who are in a vertical industry that requires them to work with XML schema (for instance e-learning) love it.
    • People who work with XML data today, love it.
    • But apparently there are still a lot of people who don’t want to work with XML in an explicit fashion. If a protocol uses it (soap), fine. If a tool uses it (for instance RDL in Reporting Services) fine. If they need to directly work with XML data, XPath, XQuery, SAX, etc… they rather not. Last week in Istanbul, nobody was really running warm for XML support. A big surprise to me. Although…I can also see why. XML isn’t simple. SOAP isn’t simpleJ It’s a great thing to have for interop, for tool builders, for storing hierarchical data and semi structured data and maybe a million other reasons, but it’s not simple. I too am longing for the day I won’t see a single tag again… (hopefully before I die).
    • Nevertheless, we are taking big strides with XML integration in .NET. Yukon will be the store for all types of data. Will of some tool support like for instance the XQuery builder and will allow SQL Procedure to be exposed directly as Web Services. This is fundamental. SQL Server will understand SOAP as well as will understand TDS. Works on Windows 2003 and Windows XP SP2. No IIS needed.

     

    The most wrongly ignored topic: T-SQL improvements

    • There is so much goodness here!
      • Common Table Expressions (hierarchical queries)
      • Improved WAITFOR offers queuing in the database.
      • Pivot and Apply
      • Out from insert update and delete statements
        For instance:
        insert into MyTable

    output inserted.id
    values (x,y)

      • Ranking functions
      • TRY CATCH for transaction abort handling
      • ‘Execute as’ to have a stored proc run using a fixed identity you can specify.
      • DDL Triggers: Trigger on CREATE/ALTER/DROP statements
    • Too much goodness to sum up. I need to spend more time here!

     

    The most debated topic: Objectspaces

    This is a real hot debate. Java developers have this debate and now I’m afraid Microsoft developers will have the debate as well. I know it’s not a SQL Server Yukon only topic but it’s hard not to discuss data access when talking databases.

    ·         My take: a good designed DAL and framework can be as efficient as an Object Relation Mapping Framework. Optimizing data access when using an OR Framework will be a challenge or will require effort comparable to building a proprietary DAL in many cases. I would only use frameworks like this if:

    o        There’s a lot of business logic running on the server with little user involvement

    o        I need to build an app on a database I don’t own with a very complex schema (let’s take SAP as an example).

    o        My boss tells me to

    ·         Some ISV’s take on this:

    o        Way cool! Every SQL statement I don’t have to write is saving me money.

    o        Hey, I wrote this already years ago!

     

     

  • Hans VB's WebLog - For FREE!!!

    TechEd Europe 2004 (Amsterdam)

    • 0 Comments

    My main objective is to evangelize (don't blame me, I don't like the word evangelism either) SQL Server 2005. Although this objective fills 100% of my time, I took on the task of deciding which sessions go into the Developer Tools and Technologies track for TechEd Europe so I can fill some other 10%. Obviously we base ourselves on the TechEd US session list but there are some differences because of regional accents, number of sessions that can be allocated and last but not least because we want to give some regional stars the opportunity to deliver their 'hit' presentations at TechEd.

    Now, finding great sessions and putting them on the agenda is easy. The hard part is dropping good sessions. I'm looking at about 150 sessions that would be worth delivering but I can only retain 72. On top of that, we are presenting at this year's TechEd quite a lot of content on Visual Studio 2005 and SQL Server 2005. I'm pretty sure many developers are looking forward to those information but the reality is that every Whidbey session will take a slot that could have been filled by a today's technology session.

    It's a dilemma, much like deciding which features will go in the next release of a your software. It reminds me of the oocasion where I had the honnor to attend a meeting of the Visual Basic PM's. One PM - I can't remember which subsystem he was responsible for - was told that he couldn't implement all the priority one features on his list. I don't think he slept well that night.

    Anyway, back to TechEd. The verdict is that there will be a 75% current tech - 25% Whidbey partition for the dev & tools track. Trying to do the right thing ain't easy.

    I find myself in Istanbul today. Although less than 4 hours flying from Belgium - where I live - a completely different type of place. Facinating.

Page 1 of 1 (3 items)