Description

Euan Garden takes on SQL Server myths. For instance, have you heard someone say that you need to be a .NET programmer to use the next version of SQL Server? Or, have you heard that SQL Server isn't scalable or performant? Euan takes those SQL Server myths
head on. (In this video you catch a glimpse of the guy performing the interview,
Jeremy Mazner, technical evangelist at Microsoft and you get to see Euan's office too).

I'm sure you were wanting a response from Euan, but I enjoy talking about "what technology or product to use". And I think it comes down to this: What makes your job easier. I am sure you could come up with a list of 10 things for both MSSQL and MySQL
that would want you to move to other side. But this really isn't the point. The point is you have work to do and if one tool helps you do that job better, than by all means that is the one you use.

I should qualify my statement here by saying I use MSSQL and wouldn't care to use MySQL. But to give you an example of what I mean I have often used Access Data access pages to give people an interface to the data. I am an ASP/ASP.NET developer and I am opening
up Access to build interfaces?? Yah, because sometimes it's just easier. Be pragmatic in your work. Work smarter and things will get easier. It means that the client/end user will get their job done easier as well.

I would like to hear however a response from MS on some of the technology advantages of MySQL - honestly I don't know.

What would you say to developers who are using MySQL to convince them to move over to MSSQL?

Iain

Euan : That's easy! We got views and triggers!

Lord don't get me started on this debate. We have MySQL right now and i'm glad to say that we are finally converting to MS SQL Server. I have not used MS SQL Server but i am finding it is less of a learning curve than MySQL.

The other thing that MS SQL has are Stored Procedures, Backup and Restore Modules, Replication Services, and above all CONSTRAINTS!!! In MySQL by default (maybe it's just the version im suing) there are not foreign key constrains. You can type them with your
CREATE TABLE syntax, but the server won't enfoce them!

Lastly, MS SQL has Enterprise Manager. Sure there are many GUI's written for MySQL, but the most popular one requires installing PHP on the server, not cool.

Thanks for the discussion, i agree that taking those types of risks more often than not steel your sleep, but in the end pay off.

Speaking of myths...

I once heard that C# was going to be a replacement for C++, i laughed. When i was asked why, i asked this person if they knew that office was written entirely in C++, and large chunks of Visual Studio are written in Managed C++, C#, and VB.NET just to prove
they could do it.

C++ isn't going anywhere, it will be around for many years, and you will continue to develop managed and unmanaged apps on the Windows platforms.

The first thing I would say is checkout our MSDE SKU which is free. Many people don't realise there is a free version of "SQL Server". It has very rich functionality, its 100% compatible with SQL Server Std and Enterprise Edition(you can just detach the database
file and attach it to one of the higher end SKUs).

Next I would say look at the maturity of the Management/Development Tools and Perf Tuning tools. Tools like Profiler, Replay, Database Tuning Advisor and Graphical Showplan can really help developers build and tune there apps.

Finally I would take a look at SQL2000 and SQL2005 and look at the range of features, the reliability, the scaleability and the performance, there is tons of information to look at, this is a great starting place:
https://www.microsoft.com/sql/

This is a great misperception about SQL Server and several of the competitors out there. MSDE is free, its free to use and free to distribute as part of your app, we changed to make it this easy a few months ago. There are not many vendors out there that
are really this free.

I think Longhorn will drive a lot of people to build managed apps faster than they they expected, just as Yukon will do.

Dealing with User Defined DataTypes written in managed languages via OLE DB, ODBC and ADO is pretty challenging, dealing with them in Managed code is a snap. Lots of the newer APIs that MS is producing are in the same bucket, VERY easy to use from managed,
some harder and more challenging in native code.

In the tools team we replaced millions of lines of C++ code in this release with C#. We also wrote some new C++ and some Managed C++ code, this is mostly in SQL Computer Manager and Profiler. The former is pure C++ the later is a mix.

In reality some of the reasons we did not write everything in managed was a resourcing issue and for other external reasons which I don't believe are valid.

On the other hand I think we wrote MC++ in some places and it is still the choice.

Many people use office as a gauge to see whether Microsoft is serious about Managed code, there should be no doubt we are very very serious about managed code but we are also a business. It was the right time to rewrite the tools for Yukon for a variety of
reasons, the timing was right that managed code was an option. The office team has not done a rewrite in many years of the main product, when they do I am sure managed will be one of their options and likely the choice. They did rewrite Windows Sharepoint
Services 2.0 in managed code as the timing was perfect.

Remember also that in the SQL Server team we wrote all of reporting services, the server and the designer, in managed code.

We are producing a lot of managed code apps as a company today and this will only increase, but more importantly many of you, our customers are producing managed code apps.

I have to say I am happy to see someone from MS come out and speak the gospel. It is VERY important that we see MS produce tools that are written in managed code, and that when others attemp the same it is possible to achieve the same level of quality
given the same level of effort. That my friend is a free market and I hope it works well for MS, because MS and any innovative company that produces platforms for developers, helps to drive technology forward.

In addition to the competitive nature of it, MS implementing purely managed code tools will prove the legitimacy of many a developer. ANSI C has enjoyed it's status for a long time because multiple platforms have supported it, in an open standard. I see C#
and the CLR capable of taking that same spotlight.

Perhaps there should be better integration between Access and MSDE - choice between legacy Access Database, or create new MSDE database. Access may prove to be a good interface for MSDE - or maybe use MSDE as it's native format.

Yes we work pretty closely with the Access team, they are working on their next version and we have spent a ton of time talking about MSDE features with them. Look out for B2 of Yukon and the MSDE feature list and you will see the fruits of some of our
work with Office and VS.