Reason:
SQL Serversecurity authentication is set to Windows only.
Try this:
Set it to sql and windows mode. Right click on SQL Server root -> Properties -> Security -> Change mode and save.
Restart the server. you are good to go now.
Tuesday 23 February 2010
Multithreading in .net - Solution
Solution
.NET provides many mechanisms to help you control threads. Another way to keep a thread blocked while another thread is processing a piece of shared memory is to use an AutoResetEvent. The AutoResetEvent class has two methods, Set and WaitOne. These two methods can be used together for controlling the blocking of a thread. When an AutoResetEvent is initialized with false, the program will stop at the line of code that calls WaitOne until the Set method is called on the AutoResetEvent. After the Set method is executed on the AutoResetEvent, the thread becomes unblocked and is allowed to proceed past WaitOne. The next time WaitOne is called, it has automatically been reset, so the program will again wait (block) at the line of code in which the WaitOne method is executing. You can use this "stop and trigger" mechanism to block on one thread until another thread is ready to free the blocked thread by calling Set. Listing 3 shows our same two threads using the AutoResetEvent to block each other while the block thread waits and the unblocked thread executes to display _threadOutput to the Console. Initially, _blockThread1 is initialized to signal false, while _blockThread2 is initialized to signal true. This means that _blockThread2 will be allowed to proceed through the WaitOne call the first time through the loop in DisplayThread_2, while _blockThread1 will block on its WaitOne call in DisplayThread_1. When the _blockThread2 reaches the end of the loop in thread 2, it signals _blockThread1 by calling Set in order to release thread 1 from its block. Thread 2 then waits in its WaitOne call until Thread 1 reaches the end of its loop and calls Set on _blockThread2. The Set called in Thread 1 releases the block on thread 2 and the process starts again. Note that if we had set both AutoResetEvents (_blockThread1 and _blockThread2) initially to signal false, then both threads would be waiting to proceed through the loop without any chance to trigger each other, and we would experience a deadlock.
Listing 3 - Alternatively Blocking threads with the AutoResetEvent
AutoResetEvent _blockThread1 = new AutoResetEvent(false);
AutoResetEvent _blockThread2 = new AutoResetEvent(true);
///
/// Thread 1, Displays that we are in thread 1
///
void DisplayThread_1()
{
while (_stopThreads == false)
{
// block thread 1 while the thread 2 is executing
_blockThread1.WaitOne();
// Set was called to free the block on thread 1, continue executing the code
Console.WriteLine("Display Thread 1");
_threadOutput = "Hello Thread 1";
Thread.Sleep(1000); // simulate a lot of processing
// tell the user what thread we are in thread #1
Console.WriteLine("Thread 1 Output --> {0}", _threadOutput);
// finished executing the code in thread 1, so unblock thread 2
_blockThread2.Set();
}
}
///
/// Thread 2, Displays that we are in thread 2
///
void DisplayThread_2()
{
while (_stopThreads == false)
{
// block thread 2 while thread 1 is executing
_blockThread2.WaitOne();
// Set was called to free the block on thread 2, continue executing the code
Console.WriteLine("Display Thread 2");
_threadOutput = "Hello Thread 2";
Thread.Sleep(1000); // simulate a lot of processing
// tell the user we are in thread #2
Console.WriteLine("Thread 2 Output --> {0}", _threadOutput);
// finished executing the code in thread 2, so unblock thread 1
_blockThread1.Set();
}
}
The output produced by listing 3 is the same output as our locking code, shown in figure 3, but the AutoResetEvent gives us some more dynamic control over how one thread can notify another thread when the current thread is done processing.
find Complete Post at :
http://www.c-sharpcorner.com/UploadFile/mgold/MultithreadingIntro10062005000439AM/MultithreadingIntro.aspx
.NET provides many mechanisms to help you control threads. Another way to keep a thread blocked while another thread is processing a piece of shared memory is to use an AutoResetEvent. The AutoResetEvent class has two methods, Set and WaitOne. These two methods can be used together for controlling the blocking of a thread. When an AutoResetEvent is initialized with false, the program will stop at the line of code that calls WaitOne until the Set method is called on the AutoResetEvent. After the Set method is executed on the AutoResetEvent, the thread becomes unblocked and is allowed to proceed past WaitOne. The next time WaitOne is called, it has automatically been reset, so the program will again wait (block) at the line of code in which the WaitOne method is executing. You can use this "stop and trigger" mechanism to block on one thread until another thread is ready to free the blocked thread by calling Set. Listing 3 shows our same two threads using the AutoResetEvent to block each other while the block thread waits and the unblocked thread executes to display _threadOutput to the Console. Initially, _blockThread1 is initialized to signal false, while _blockThread2 is initialized to signal true. This means that _blockThread2 will be allowed to proceed through the WaitOne call the first time through the loop in DisplayThread_2, while _blockThread1 will block on its WaitOne call in DisplayThread_1. When the _blockThread2 reaches the end of the loop in thread 2, it signals _blockThread1 by calling Set in order to release thread 1 from its block. Thread 2 then waits in its WaitOne call until Thread 1 reaches the end of its loop and calls Set on _blockThread2. The Set called in Thread 1 releases the block on thread 2 and the process starts again. Note that if we had set both AutoResetEvents (_blockThread1 and _blockThread2) initially to signal false, then both threads would be waiting to proceed through the loop without any chance to trigger each other, and we would experience a deadlock.
Listing 3 - Alternatively Blocking threads with the AutoResetEvent
AutoResetEvent _blockThread1 = new AutoResetEvent(false);
AutoResetEvent _blockThread2 = new AutoResetEvent(true);
///
/// Thread 1, Displays that we are in thread 1
///
void DisplayThread_1()
{
while (_stopThreads == false)
{
// block thread 1 while the thread 2 is executing
_blockThread1.WaitOne();
// Set was called to free the block on thread 1, continue executing the code
Console.WriteLine("Display Thread 1");
_threadOutput = "Hello Thread 1";
Thread.Sleep(1000); // simulate a lot of processing
// tell the user what thread we are in thread #1
Console.WriteLine("Thread 1 Output --> {0}", _threadOutput);
// finished executing the code in thread 1, so unblock thread 2
_blockThread2.Set();
}
}
///
/// Thread 2, Displays that we are in thread 2
///
void DisplayThread_2()
{
while (_stopThreads == false)
{
// block thread 2 while thread 1 is executing
_blockThread2.WaitOne();
// Set was called to free the block on thread 2, continue executing the code
Console.WriteLine("Display Thread 2");
_threadOutput = "Hello Thread 2";
Thread.Sleep(1000); // simulate a lot of processing
// tell the user we are in thread #2
Console.WriteLine("Thread 2 Output --> {0}", _threadOutput);
// finished executing the code in thread 2, so unblock thread 1
_blockThread1.Set();
}
}
The output produced by listing 3 is the same output as our locking code, shown in figure 3, but the AutoResetEvent gives us some more dynamic control over how one thread can notify another thread when the current thread is done processing.
find Complete Post at :
http://www.c-sharpcorner.com/UploadFile/mgold/MultithreadingIntro10062005000439AM/MultithreadingIntro.aspx
Thursday 18 February 2010
Explicitly Call Dispose or Close on Resources You Open
If you use objects that implement the IDisposable interface, make sure you call the Dispose method of the object or the Close method if one is provided. Failing to call Close or Dispose prolongs the life of the object in memory long after the client stops using it. This defers the cleanup and can contribute to memory pressure. Database connection and files are examples of shared resources that should be explicitly closed. The finally clause of the try/finally block is a good place to ensure that the Close or Dispose method of the object is called.
Try
conn.Open()
…Finally
If Not(conn Is Nothing) Then
conn.Close()
End If
End Try
In Visual C#®, you can wrap resources that should be disposed, by using a using block. When the using block completes, Dispose is called on the object listed in the brackets on the using statement. The following code fragment shows how you can wrap resources that should be disposed by using a using block.
SqlConnection conn = new SqlConnection(connString);
using (conn)
{
conn.Open();
. . .
} // Dispose is automatically called on the connection object conn here.
Try
conn.Open()
…Finally
If Not(conn Is Nothing) Then
conn.Close()
End If
End Try
In Visual C#®, you can wrap resources that should be disposed, by using a using block. When the using block completes, Dispose is called on the object listed in the brackets on the using statement. The following code fragment shows how you can wrap resources that should be disposed by using a using block.
SqlConnection conn = new SqlConnection(connString);
using (conn)
{
conn.Open();
. . .
} // Dispose is automatically called on the connection object conn here.
Wednesday 10 February 2010
Configuration Settings that Impact Performance
When an ASP.NET page is visited for the first time (or the first time after it has changed), its declarative markup must be converted into a class and this class must be compiled. If the web application uses automatic compilation then the page's code-behind class needs to be compiled, too. You can configure an assortment of compilation options via the Web.config file's element.
The debug attribute is one of the most important attributes in the element. If the debug attribute is set to "true" then the compiled assemblies include debug symbols, which are needed when debugging an application in Visual Studio. But debug symbols increase the size of the assembly and impose additional memory requirements when running the code. Furthermore, when the debug attribute is set to "true" any content returned by WebResource.axd is not cached, meaning that each time a user visits a page they will need to re-download the static content returned by WebResource.axd.
Note: WebResource.axd is a built-in HTTP Handler introduced in ASP.NET 2.0 that server controls use to retrieve embedded resources, such as script files, images, CSS files, and other content. For more information on how WebResource.axd works and how you can use it to access embedded resources from your custom server controls, see Accessing Embedded Resources Through a URL Using WebResource.axd.
The element's debug attribute is usually set to "true" in the development environment. In fact, this attribute must be set to "true" in order to debug a web application; if you try to debug an ASP.NET application from Visual Studio and the debug attribute is set to "false", Visual Studio will display a message explaining that the application cannot be debugged until the debug attribute is set to "true" and will offer to make this change for you.
You should never have the debug attribute set to "true" in a production environment because of its impact on performance.
The debug attribute is one of the most important attributes in the
Note: WebResource.axd is a built-in HTTP Handler introduced in ASP.NET 2.0 that server controls use to retrieve embedded resources, such as script files, images, CSS files, and other content. For more information on how WebResource.axd works and how you can use it to access embedded resources from your custom server controls, see Accessing Embedded Resources Through a URL Using WebResource.axd.
The
You should never have the debug attribute set to "true" in a production environment because of its impact on performance.
Subscribe to:
Posts (Atom)
