I do a lot of SQL Server Desktop Edition instance testing and I cobbled together this script from BOL and other scripts I've seen posted. It is intended to show version, service pack level, machine and instance name and the security type among other information. Hopefully someone else may find it of use.
SELECT SERVERPROPERTY('ProductVersion') as Product_Version
,SERVERPROPERTY('Edition') as Edition
,SERVERPROPERTY('ProductLevel') as Product_Level
,SERVERPROPERTY('ServerName') as Server_Name
,SERVERPROPERTY('MachineName') as Machine_Name
,SERVERPROPERTY('InstanceName') as Instance_Name
go
select SERVERPROPERTY('LicenseType') as License_Type
,(CASE
WHEN CONVERT(char(5), SERVERPROPERTY('ISIntegratedSecurityOnly')) = 1
THEN 'Integrated or Windows Security'
WHEN CONVERT(char(5), SERVERPROPERTY('ISIntegratedSecurityOnly')) = 0
--0 is not integrated
THEN 'SQL Server Security'
ELSE 'INVALID INPUT/ERROR'
END) AS Security_Type
,SERVERPROPERTY('Collation') as Collation
go 
2007-10-02 (first published: 2002-06-20)
15,432 reads
I have always read that 8060 bytes is the maximum size. This is stated over and over again in Books Online, the MS site and numerous other sites, including this one. However a post in our forum recently questioned this. I decided to verify the problem and do a little research.
2007-10-02 (first published: 2002-02-07)
37,303 reads
The User_Defined_Functions.exe file contains the User-Defined Functions white paper. The User-Defined functions white paper outlines the characteristics of the new user-defined function (UDF) feature that is introduced in Microsoft SQL Server 2000. The white paper also summarizes how you can create your own Transact-SQL functions to extend the programmability of Transact-SQL.
2001-08-31
2,233 reads
The following stored procedure will demonstrate the use of cursor metadata. Using cursor metadata we can get information about an SQL statement and use that information to dynamically generate other code such as HTML or other stored procedures.
2001-07-27
5,180 reads
ne of the issues you face when building Web applications is handling the errors you encounter when interacting with a back-end database. I was recently working with someone to create a new Web site with SQL Server™, ActiveX® Data Objects (ADO), and ASP. Lots of little things came up that I thought were worth sharing with MIND readers, so I'll focus this column on what I learned from this experience and the solutions to many of the problems I faced.
2001-07-13
1,579 reads