I needed to compress a lot of files into individual zip archives – I did not want to do it manually 🙂
Add the following to a bat file and every file with the extension txt will be compressed into a Zip archive with 7-Zip file archiver:
For %%f in (*.txt) do 7z.exe a -tzip %%f.zip %%f
E.g. a.txt will be compressed to the archive a.txt.zip
This was not exactly what I needed, as the dual extension caused problems in later processing. In needed to remove the extension preceding the zip extension – therefore:
For %%f in (*.txt) do 7z.exe a -tzip %%~nf.zip %%f
E.g. a.txt will be compressed to the archive a.zip
That’s it 🙂
Working with SQL Server it is often important to know which edition, version and service pack applied to the instance.
This information easily retrieve with either of these two system functions ServerProperty or @@Version:
Both of the returns roughly the same information, but I tend to use the @@Version function as it easier to remember and type.
With the ServerProperty function additional information can be retrieved like MachineName, InstanceName or BuildClrVersion. See more about the ServerProperty function on MSDN.
From the build number alone it is possible to figure out which version of the SQL Server and Service Packs applied via the below table:
|SQL Server 2008 R2
|SQL Server 2008
|SQL Server 2005
|SQL Server 2000
Credit for the above table is due to this site.
Update April 30th 2010: Added SQL Server 2008 R2 RTM build number
Update October 4th 2010: Added SQL Server 2008 SP2 build number
I had to migrate a SQL Server 2008 instance on to new hardware.
I choose to detach the databases and attach the databases on the new SQL Server 2008 instance on the new hardware. This was easy, but the origin SQL Server instance used mixed SQL Server and Windows Authentication Mode. This also meant that I had to migrate SQL Server logins, as the logins where a mix of SQL Server logins and Active Directory domain accounts/groups.
Both the SQL Server logins and domain accounts/groups has an unique SID (Security Identifier), which ties the logins in the SQL Server with the users in the database.
While the domain accounts/groups resides in the Active Directory domain controllers, the SQL Server logins only resides in the SQL Server. This means, moving domain accounts/groups is easy, by just creating the same users in the new SQL Server instance, but SQL Server logins is not. I could either choose to:
- Recreate the SQL Server logins with new users in each of the databases, as new SQL Server logins will get new SIDs and therefore not be tied to the old database users. This also requires that you know all the passwords – alternative reconfigure all the client applications using SQL Server logins 🙁
- Transfer the SQL Server logins with SID and password 🙂
How to transfer SQL Server logins? See the KB article: How to transfer the logins and the passwords between instances of SQL Server 2005 and SQL Server 2008. Easy 🙂