C#: To determine OS Architecture


To determine OS Architecture

private Boolean is64BitOperatingSystem()
RegistryKey localEnvironment = Registry.LocalMachine.OpenSubKey(“SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Environment”);
String processorArchitecture = (String) localEnvironment.GetValue(“PROCESSOR_ARCHITECTURE”);
if (processorArchitecture.Equals(“x86”)) {
return false;
else {
return true;


Installer: Merge Module (.msm File)


Merge Module (.msm File)

Visual Studio 6.0

Also referred to as "merge package file." A merge module (.msm file) is a single package that includes all files, resources, registry entries, and setup logic to install a shared component. Merge modules include all the information necessary for a Microsoft® Windows® installer to install a shared component.

Merge modules are consumed by installer package (.msi) files. Microsoft® Visual Studio® Installer facilitates both creating .msm files and consuming them in an .msi file. You can distribute your shared components in merge modules, and you can use shared components by including the appropriate .msm files in your .msi file.


If you’re using a batch file to install your app, you could try executing "msiexec <filename>.msm".

Or, if you want to install it programmatically, try doing a System.Diagnostics.Process.Start("filename.msm").

Installer: WiX (Windows Installer XML) Tutorial


WiX Tutorial

Introduction to the Windows Installer XML Toolset

The Windows Installer XML (WiX) is a toolset that builds Windows installation packages from XML source code.

The toolset provides both a command line environment that developers may either integrate into their oldstyle Makefile build processes or use the newer MSBuild technology from inside integrated development environments like Microsoft’s Visual Studio or SharpDevelop to build their MSI and MSM setup packages.

WiX is an open source project, originally developed by Microsoft

To summarize the features and advantages of the toolset:

  • declarative approach
  • unrestricted access to Windows Installer functionality
  • source code instead of GUI-based assembly of information
  • complete integration into application build processes
  • possible integration with application development
  • support for team development, both in-house and third-party
  • free, open source

Microsoft itself is switching to WiX with all its major software packages. Just as an example, the setup of Microsoft Office 2007 was developed entirely with WiX.


All these will be described in the source files fed to the WiX compiler. The toolset consists of several parts and we will use two of them to compile our installation packages. Assuming we have prepared a Sample.wxs file, the command

candle.exe Sample.wxs

will perform the first phase of the compilation, creating Sample.wixobj, a half-digested file (this one is still XML but its internal structure is irrelevant to us; think about it as an object file in usual compiler parlance). The second command

light.exe Sample.wixobj

will turn this intermediate representation into our final package, a Sample.msi file. Much like a compiler and a linker.

Also note that WiX is not an installation environment of its own. To put it simply, it is a comfortable, XML-style way to describe your installation requirements that gets translated into Windows Installer .msi databases by its compiler and linker. In this respect, WiX is a relatively thin wrapper around Windows Installer technology.

SQL: Quick Overview: Temporary Tables in SQL Server 2005


Quick Overview: Temporary Tables in SQL Server 2005

By Abhijit Jana | 22 Sep 2009

Table of Contents

Creating Temporary Table in SQL Server 2005 Storage Location of Temporary Table When to Use Temporary Tables? Points to Remember Before Using Temporary Tables Alternative Approach: Table Variable


SQL Server provides the concept of temporary table which helps the developer in a great way. These tables can be created at runtime and can do the all kinds of operations that one normal table can do. But, based on the table types, the scope is limited. These tables are created inside tempdb database.

In this article, I am just going to give a quick overview for beginners on those temporary tables. Please give your valuable suggestions and feedback to improve this article.

Different Types of Temporary Tables

SQL Server provides two types of temp tables based on the behavior and scope of the table. These are:

  • Local Temp Table
  • Global Temp Table

Local Temp Table

Local temp tables are only available to the current connection for the user; and they are automatically deleted when the user disconnects from instances. Local temporary table name is stared with hash ("#") sign.

Global Temp Table

Global Temporary tables name starts with a double hash ("##"). Once this table has been created by a connection, like a permanent table it is then available to any user by any connection. It can only be deleted once all connections have been closed.

Creating Temporary Table in SQL Server 2005

As I have already discussed, there are two types of temporary tables available. Here I am going to describe each of them.

Local Temporary Table

The syntax given below is used to create a local Temp table in SQL Server 2005:

Collapse | Copy Code

CREATE TABLE #LocalTempTable(
UserID int,
UserName varchar(50), 
UserAddress varchar(150))

The above script will create a temporary table in tempdb database. We can insert or delete records in the temporary table similar to a general table like:

Collapse | Copy Code

insert into #LocalTempTable values ( 1, 'Abhijit','India');

Now select records from that table:

Collapse | Copy Code

select * from #LocalTempTable

After execution of all these statements, if you close the query window and again execute "Insert" or "Select" Command, it will throw the following error:

Collapse | Copy Code

Msg 208, Level 16, State 0, Line 1
Invalid object name '#LocalTempTable'.

This is because the scope of Local Temporary table is only bounded with the current connection of current user.

Global Temporary Table

The scope of Global temporary table is the same for the entire user for a particular connection. We need to put "##" with the name of Global temporary tables. Below is the syntax for creating a Global Temporary Table:

Collapse | Copy Code

CREATE TABLE ##NewGlobalTempTable(
UserID int,
UserName varchar(50), 
UserAddress varchar(150))

The above script will create a temporary table in tempdb database. We can insert or delete records in the temporary table similar to a general table like:

Collapse | Copy Code

insert into ##NewGlobalTempTable values ( 1, 'Abhijit','India');

Now select records from that table:

Collapse | Copy Code

select * from ##NewGlobalTempTable

Global temporary tables are visible to all SQL Server connections. When you create one of these, all the users can see it.

Storage Location of Temporary Table

Temporary tables are stored inside the Temporary Folder of tempdb. Whenever we create a temporary table, it goes to Temporary folder of tempdb database.

Now, if we deeply look into the name of Local Temporary table names, a ‘dash‘ is associated with each and every table name along with an ID. Have a look at the image below:

SQL server does all this automatically, we do not need to worry about this; we need to only use the table name.

When to Use Temporary Tables?

Below are the scenarios where we can use temporary tables:

  • When we are doing large number of row manipulation in stored procedures.
  • This is useful to replace the cursor. We can store the result set data into a temp table, then we can manipulate the data from there.
  • When we are having a complex join operation.

Points to Remember Before Using Temporary Tables

  • Temporary table created on tempdb of SQL Server. This is a separate database. So, this is an additional overhead and can causes performance issues.
  • Number of rows and columns need to be as minimum as needed.
  • Tables need to be deleted when they are done with their work.

Alternative Approach: Table Variable

Alternative of Temporary table is the Table variable which can do all kinds of operations that we can perform in Temp table. Below is the syntax for using Table variable.

Collapse | Copy Code

Declare @TempTableVariable TABLE(
UserID int,
UserName varchar(50), 
UserAddress varchar(150))

The below scripts are used to insert and read the records for Tablevariables:

Collapse | Copy Code

insert into @TempTableVariable values ( 1, 'Abhijit','India');

Now select records from that tablevariable:

Collapse | Copy Code

select * from @TempTableVariable

When to Use Table Variable Over Temp Table

Tablevariable is always useful for less data. If the result set returns a large number of records, we need to go for temp table.

SQL: Derived Tables in SQL


Derived Tables in SQL

The power of SQL Server never fails to amaze me; it literally seems that you can do just about anything in SQL. All you need is a little creativity and knowledge of the syntax, and you can put the power of SQL behind your web application. One of the neatest things I’ve yet done with SQL Server is using derived tables.

If you’ve used a VIEW before, you’ve used a more formal, more correct form of a derived table. For example, we could do the following:

 CREATE VIEW vwEmployeesFromNewYork AS
 SELECT * FROM Employee
 WHERE State = "NY"

Then if we wanted to see all of the Employees from New York with the last name Smith, ordered alphabetically, we could write:

 SELECT LastName, FirstName
 FROM vwEmployeesFromNewYork
 WHERE LastName = "Smith"
 ORDER BY FirstName

However, using derived tables, we could eliminate the view entirely. (Of course the view could be eliminated by simply adding an "AND State = "NY"" to the above WHERE clause, but what’s important here is the concept, not the example!) Here is the same resultset as above but with the use of a derived table in place of a veiw:

 SELECT LastName, FirstName
 (SELECT * FROM Employee
 WHERE State = "NY") AS EmployeeDerivedTable
 WHERE LastName = "Smith"
 ORDER BY FirstName

Isn’t that neat? What we are doing is first getting the result set from our derived table (the SELECT statement in the FROM clause). Once we have that resultset, it is as though it was a table in itself. We then perform the SELECT on the derived table, returning our results! You can find another example of using derived tables here on 4GuysFromRolla.com in the article Obtaining Ranked Values from a Table page.

SQL SERVER – Simple Example of Reading XML File Using T-SQL


SQL SERVER – Simple Example of Reading XML File Using T-SQL

February 13, 2009 by pinaldave

In one of the previous article we have seen how we can create XML file using SELECT statement SQL SERVER – Simple Example of Creating XML File Using T-SQL. Today we will see how we can read the XML file using the SELECT statement.

Following is the XML which we will read using T-SQL:

Following is the T-SQL script which we will be used to read the XML:

SET @MyXML = '<SampleXML>
< Colors>
< Color1>White</Color1>
< Color2>Blue</Color2>
< Color3>Black</Color3>
< Color4 Special="Light">Green</Color4>
< Color5>Red</Color5>
< /Colors>
< Fruits>
< Fruits1>Apple</Fruits1>
< Fruits2>Pineapple</Fruits2>
< Fruits3>Grapes</Fruits3>
< Fruits4>Melon</Fruits4>
< /Fruits>
< /SampleXML>'

a.b.value(‘Colors[1]/Color1[1]‘,‘varchar(10)’) AS Color1,
a.b.value(‘Colors[1]/Color2[1]‘,‘varchar(10)’) AS Color2,
a.b.value(‘Colors[1]/Color3[1]‘,‘varchar(10)’) AS Color3,
a.b.value(‘Colors[1]/Color4[1]/@Special’,‘varchar(10)’)+‘ ’+
+a.b.value(‘Colors[1]/Color4[1]‘,‘varchar(10)’) AS Color4,
a.b.value(‘Colors[1]/Color5[1]‘,‘varchar(10)’) AS Color5,
a.b.value(‘Fruits[1]/Fruits1[1]‘,‘varchar(10)’) AS Fruits1,
a.b.value(‘Fruits[1]/Fruits2[1]‘,‘varchar(10)’) AS Fruits2,
a.b.value(‘Fruits[1]/Fruits3[1]‘,‘varchar(10)’) AS Fruits3,
a.b.value(‘Fruits[1]/Fruits4[1]‘,‘varchar(10)’) AS Fruits4
FROM @MyXML.nodes(‘SampleXML’) a(b)

Please note in above T-SQL statement XML attributes is read the same as XML Value.