To SQL or not to SQL

Windows Server 2003 SP1 RTM

At last, Service Pack 1 for Windows Server 2003 is out. Good news. More security.

Download page. At 337'230 KB, it is a big one. Windows Update has it too.

Newsgroups will wake up soon to it.

SQL Server 2005 - What will it not support?

I've been busy sticking my head deep into SQL Server 2005. What is missing?

1. Backup compression (like Sybase) is still not available. Typically, most databases not containing BLOBs shrink from 1Gb down to 220Mb. The benefits are tremendous as there is less Disk I/O, resulting in better dump performance (CPU cycles are generally not in short supply so the additional overhead does not hurt), and the dump takes much less space on disk. You backup software then needs to drag a lot less over the network when it is writing to tape. Yes, there is commercial stuff out there, but when you manage 250 servers, you can not roll out their hotfixes every few weeks because of bugs. sqlwish@microsoft.com has heard about it already.
2. Installations of SQL Server 7.0 will not be supported by SQL Server 2005 Management Studio. Not really an issue, but most people have been assuming that it will as SQL 2000 Enterprise Manager did.

Up to this point, that is about all.

I am busy with preparing a bunch of presentations for various conferences, and my demos area bit gutsy for Beta software. 4 Node clusters, with log shipping and database mirroring, in one. Of course, all running on Microsoft Virtual Server. Watch this Blog for when the presentations will show up near you.

TechDays 2005 over at Last!

Done at last, my presentation is over, last one of the day, last day of the conference, and now I can relax.

SQL Server 2005 Administration. Here it is for download (3.5Mb)

If you have any questions, mike@epprecht.net is the address.

There were some awesome presentations. Kimberly L. Tripp was her great self again. All the presentations were good, but it was difficult to fit everything into 60 minutes plus 15 minutes for question and answers.

Well done to Microsoft Switzerland staff.

TechDays 2005, Switzerland

I am presenting again.

This time, at the Swiss TechDays 2005, in Interlaken. My topic: "SQL Server 2005 Administration and new Features". 16 and 17 March 2005.

Kimberly L. Tripp, a fellow MVP, will be there presenting too.

70% of the event is in German, with the rest being in English.

Kimberly Tripp in Zurich

In a run up to next weeks Swiss TechDays 2005, Kimberly L. Tripp will be doing a evening presentation "SQL Server 2000 Performance Best Practices and Getting Ready for SQL Server 2005". The will be on Monday 14 March, at 18:30 in Zurich. Venue is still to be advised.

For more information, visit .NET Managed User Group of Switzerland's site.

SQL Server 2005, Beta 2, CTP February 2005

I had no plans for the weekend, but Microsoft just released to beta testers, SQL Server 2005, Beta 2, Community Technical Preview February 2005. The CTP's are interim release of Beta 2, giving Microsoft good feedback on issues that still need to be fixed.

Today, IDW 14 for Visual Studio.NET 2005 Beta 1 should be out.

Big weekend of hanging around the Beta Newsgroups and trying to figure out why some of my code no longer works.

Expect me to be grumpy on Monday morning....again.

ANSI SQL-92 Compatibility

I have been doing some testing of Sybase T-SQL code that could quite easily be migrated to Microsoft SQL Server. Of course, the horrible *=, =* join syntax is still used, among other things.

How can you decide if the code that is there is really appropriate?

One was is to enforce ANSI SQL-92 standards. Well, each DB vendor implements ANSI SQL-92, on their own terms. SQL Server supports functionality that Oracle or Sybase decided to leave out, and visa versa. Fun.

Well, for SQL Server, to test if the code is actually compatible to Microsoft's subset of ANSI SQL-92, there is a SET option to warn you.

SET FIPS_FLAGGER

Great name, but FIPS (Federal Information Processing Standard) 127-2, the standard for computer systems purchased by the United States government, is what Microsoft has decided to enforce. FIPS 127-2 is based on ANSI SQL-92. So we have a Standard, based on a Standard, based on a Standard.

Books online has a bit of information on this SET option, but there is nothing that says exactly was is expected in each level. I guess, if you want to be sure the code will work reasonably well across DB vendors, Full is your only option.

SET FIPS_FLAGGER 'FULL' really takes your code and tells you that it is crap. Don't look at the output if you are having a bad day.

ANSI SQL-99.....well, that is finding it's way into SQL Server 2005 and I am not picking on that yet.