Windows 7 on VMWare Workstation 6.5

I was at the Microsoft Canada Energize IT Windows 7 Installfest event in Ottawa and volunteered to assist with the attendees while they were doing the installation. While the supported installation options during the event were clean install, upgrade, dual boot or virtualization using Hyper-V, Virtual PC or Virtual Server, a few of those who came were asking if they can install it on VMWare. Now, I have been working with VMWare for years now and my take on this is if its a Microsoft operating system and it runs on the Microsoft Virtualization products, it will definitely run on VMWare. I was making suggestions about how to go about it and the caveats when working with VMWare, I have never seen Windows 7 yet. So what I did was to fire up my VMWare Workstation and started installing Windows 7, just so I can answer the questions knowing I had he experience of doing it rather than just saying "I know it will work." I used the ISO image provided by Microsoft and the installation went really fast. If you've installed Windows Vista or Windows Server 2008 before, the process is pretty similar. I guess I'm on my way to playing with the Windows 7 image just to get the hang of it. And one thing is for sure, it will work on VMWare - even with 512MB of RAM.

Changing a SQL Server 2000 login

WARNING: This is not a recommended approach. Use at your own risk

While SQL Server 2005 has the ALTER LOGIN statement to change the properties of a SQL Server login account, SQL Server 2000 does not have such a command. Unfortunately, there are cases where you need to simply rename the login due to a misspelled name or a change management policy. The proper way to do it in SQL Server 2000 is to create the new login, map the permissions and roles of the existing login that you wish to change to this new login and, then, drop the old login. I wouldn't want to go thru that if I only have to rename the login. The only simpler way to do it is to modify the system tables. As I've said, it is not recommended to modify the system tables and/or objects directly so bear in mind that doing this would be at your own risk. This would also require that you torn on allowing ad hoc updates to system tables and turning it off afterwards

sp_CONFIGURE 'ALLOW UPDATES', 1
GO
RECONFIGURE WITH OVERRIDE
GO

UPDATE db..sysusers
SET name='newLogin'
WHERE
name='oldLogin'

UPDATE master..sysxlogins
SET name='newLogin'
WHERE
name='oldLogin'

sp_CONFIGURE 'ALLOW UPDATES', 0
GO
RECONFIGURE WITH OVERRIDE
GO

A similar stored procedure is described here