April 2005 - Posts

SQL Server 2000 on x64

The question has come up a few times in the newsgroups.

Does SQL Server 2000 run on x64?

SQL Serrver 2005 supports it already, but SQL Server 2000 does not.

Service Pack 4 for SQL Server 2000 was mooted to support it.

The answer I got from Microsoft today: “Microsoft is still finalizing this.” So, once they have made a decision, there will be a public statement on this.

Posted by Mike Epprecht | with no comments
Filed under:

April CTP is 'feature complete'

It is official that what is in the April CTP, is what will, with a 99.999% probability, be in the RTM of SQL Server 2005.

Microsoft is saying that it is 'feature complete', so from here onwards, it is bug fixes and performance enhancements only.

The letter from Paul Flessner, Senior Vice President of the Server Applications at Microsoft: http://www.microsoft.com/sql/2005/productinfo/letter.asp

Since I has such a nice evening last night fighting installation problems, I will only really get time tonight to dig into the product and see what is 'missing'. I did notice that the SQL Server Management Studio did behave better and seemed to have more features.

The version number of the April CTP (internally referred to as IDW14) is v9.00.1116.08

During setup, I did notice that if Integrated Security was selected, no default password for the sa account was required. This changed from IDW 13 where it forced you to enter one. I think it is a bug so I will file it as one.

Also, once the client tools were installed, it is not possible to add the Sample Databases and Sample Code by re-running setup. So, if you forget it, you can't have it. Bugged it.

So I get to file 3 bugs for 6 hours work.......success.

UPDATE:

The sa issue is a bug and will be fixed.

The client tools issue, well, once the client tools are installed, you have to maintain them though Add/Remove Programs, then you can add these additional options. Not too clear during setup, but one for the books as I think it will be a popular question around RTM.

OK, so I got to file 2 bugs. Still good.

Posted by Mike Epprecht | with no comments
Filed under:

April CTP install is failing

Well, the SQL Server 2005 April CTP is failing on installing the database components.

In the Beta newsgroups, more people are popping up with the same issue, mostly Express Editions.

Some of the error:

Product         : SQL Server Database Services
Error           : SQL Server Setup could not connect to the database service
for server configuration. The error was: [Microsoft][SQL Native Client]SQL
Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF].
Refer to server error logs and setup logs for more information. For details
on how to view setup logs, see "How to View Setup Log Files" in SQL Server
Books Online.


The SQL Error log shows a clean startup and a clean shutdown at request from the installer.
The instance is running at the time of the failure and I have verified it is running in Services and process is there in Task Manager..

Looking at
*_SQL.log, it shows "Login timeout expired" as being the reason.

I will persist and get the issue......

UPDATE:

I seem to have nailed it.
 
When the dialogue pops up with the connection failure message, I ran "SQLServerManager.msc", the SQL Server Configuration Manager, and enabled for the SQL Native Client Configuration, under Client Protocols, Named Pipes and Shared Memory (TCP/IP is enabled by default).
 
Once I did this, I could press retry and the installation completed successfully.
 
sqlcmd and sqlcmd90 both retuned the same errors as the installation routine when they could no connect.
 

UPDATE 2:

"SQLServerManager.msc", the SQL Server Configuration Manager, is not installed by the time the failure occurs. What I did was to first install the client tools only, then re-run setup and install the Database Engine.
 

UPDATE 3:

Some people have hinted that this problem might be caused by SNAC importing the SQL Server 2000 client configuration settings. For me, TCP/IP and Named Pipes was enabled, and SNAC only chose to enable TCP/IP on the install. I don't think this is the cause.
 
 
Posted by Mike Epprecht | 3 comment(s)
Filed under:

SQL Server 2005 Beta 2, April CTP Ships

So, the long awaited April CTP for SQL Server 2005 went up on MSDN downloads today.

VS.NET 2005 Beta 2 went up on Friday.

The SQL Server install requires Windows Installer v3.0 (Windows XP SP2 and Windows Server 2003 SP1 have it already, other platforms do not). It is documented in the ReadMe file, and where to get it too.

Download is in progress...hope to have it by the morning.

Posted by Mike Epprecht | with no comments
Filed under:

How to become a MVP

Very nice post here on tips on how to become an MVP.

Robert has summed it up to a point where I agree with him.

 

Posted by Mike Epprecht | with no comments
Filed under:

http://classicvb.org/

http://classicvb.org/

Visual Basic 6.0 support died 31 March 2005. Rightly so.

<RANT ON>

There is far too much badly architected, badly developed and security-less VB v1.0-6.0 code out there. And it is a risk to every business that is using it.

Now how can a developer not want to move forward, improve on what he/she has written, and at the same time, keep up with the technology boom that put them where they are?

If a VB 6.0 developer can not handle the migration to VB.NET (or better c#), maybe the developer needs a LOT of re-training, or be re-evaluated if he/she is actually good enough for the position held. Developers generally earn a lot of money, but in most cases, they are not worth it.

Yes, a re-write will expose the security holes and the coding monstrosity that was created over the years, but maybe it is good for the IT industry. A good clean out will help drive down costs (those developers who are not productive and competent will be pushed out the industry) and at the same time, sort out all the security flaws that are lying around.

In my opinion, it is time to do a clean sweep. Developers who can not be multi-faceted, not willing to learn the newer languages like c# and Java have no place in this industry. A corporation needs someone who can work on code that runs on the Unix/Linux platforms, and at the same time, pretty and secure UI Windows desktop code (no, I don't believe that Java is the answer to everything, actually, far from that).

Microsoft kept everyone warm and cozy too long. The brutal reality is here. Java is mainstream, c# is getting there, VB has been left behind in the corporate environment. The large corporates have had too much trouble with mediocre VB applications that just don't work in a properly "locked-down" desktop environment.

What about the small company who runs on VB? Well, that same company is still running, now, unsupported Windows 95 and Windows 98. They still will in 2 years time (until the hardware dies and nothing new will run the old Windows). They are not spending 3-5% of turnover on IT. For them, they can wait out this round of development upgrades, and then in 2 years time, get something that works better, and is secure, and will run on Windows Longhorn.

Maybe Microsoft should not have made VB.NET, as it was trying to be too backward compatible to be really helpful to the average developer. It probably hurt the developer by extending their IT career when they should have left it a long time ago.

<RANT OFF>

VB 1.0, 2.0, 3.0, 4.0, 5.0 and 6.0, I started out my career with you, I used your heavily over the years, but I outgrew you. So did Microsoft.

RIP.

Long live c# and SQL Server!

Posted by Mike Epprecht | with no comments
Filed under:

25th April seems to be it.....

Looks like Beta 2 of Visual Studio 2005 will be showing up 25th April.

Now I am wondering if that means Beta 3 of SQL Server 2005. It will be a later IDW than 13, possible IDW 14, but are they going to make IDW 14 = Beta 3?

http://www.microsoft.com/emea/msdn/betaexperience/

Time will only tell......

Posted by Mike Epprecht | with no comments
Filed under: