Why the SQL Server 2008 IntelliSense doesn’t work?

First of all, please check your text editor setting to make sure you have already turn on the IntelliSense function. To do so by clicking Tools > Options > Text Editor > Transact SQL > IntelliSence, and make sure the Enable IntelliSense checkbox is ticked (it should be ticked defaulted).

If the IntelliSense feature still doesn’t show then you may connected to a old version of SQL Server. The SQL Server 2008 IntelliSense only works with SQL Server 2008 database. Yeah, what a stupid reason :)

Managing ASP.NET Navigation

by Mike Gunderloy
04/08/2003

In an ASP.NET application, you can move between Web Forms in a variety of ways: with hyperlinks, with Response.Redirect, with Server.Transfer, or with Server.Execute. In this article, I will take a look at these various navigation methods and help you choose the appropriate one for your application.

Hyperlinks

The simplest possible way to navigate from one Web Form to another is with an HTML hyperlink control. On a Web Form, that might look like this:

<a href="WebForm2.aspx">WebForm2</a>

When the user clicks on the hyperlink, WebForm2.aspx is served up to their browser. You can use this technique just about anywhere, including on HTML pages and in classic ASP. ASP.NET gives you another alternative, the HyperLink Web Server control:

<form id="Form1" method="post" runat="server">
    <asp:HyperLink id="HyperLink1" runat="server"
    NavigateUrl="WebForm2.aspx">WebForm2</asp:HyperLink>
</form>

At runtime, this HTML has exactly the same effect as the first example, since ASP.NET renders the HyperLink Web Server control as an HTML hyperlink control. There is one key difference, though: the Web Server control can be programmed on the server side. In particular, you can change its NavigateUrl property in code, opening up the possibility of a hyperlink whose destination depends on some part of your application's state:

Private Sub Button1_Click( _ 
    ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
        Handles Button1.Click 
        HyperLink1.NavigateUrl = "WebForm3.aspx" 
End Sub

If the user clicks on the hyperlink after this code has executed, then the link will serve up WebForm3.aspx instead of WebForm2.aspx.

Controlling Transfers Yourself

Although hyperlinks do transfer your application from one page to another, they do so completely under the control of the user. Sometimes it's convenient to control the entire process in code yourself, including deciding when to move to another page. As it happens, ASP.NET provides three different methods to accomplish this. You can call the Redirect method of the Response object, or the Transfer or Execute methods of the Server object. Although they behave very similarly, there are differences between these three methods.

Response.Redirect

The Response.Redirect method causes the browser to connect to a specified URL. When the Response.Redirect() method is called, it creates a response whose header contains a 302 (Object Moved) status code and the target URL. When the browser receives this response from the server, it uses this header information to generate another HTTP request to the new URL. When using the Response.Redirect method, the redirection happens at the client side and involves two round trips to the server: one to request the original page, which is met by the 302 response, and then a second to request the redirected page.

Server.Transfer

The Server.Transfer method transfers execution from the current ASPX file to another ASPX file on the same web Server. When your code calls the Server.Transfer method, the current ASPX page terminates execution and the flow of control is transferred to another ASPX page. The new ASPX page still uses the response stream created by the prior ASPX page. When you use this method to navigate between pages, the URL in the browser still shows the original page, because the redirection occurs on the server side and the browser remains unaware of the transfer.

By default, the Server.Transfer method does not pass the form data or the query string of the original page request to the transferred page. But you can preserve the form data and query string of the original page by setting the optional second argument of the method to True. When you use this technique, though, you need to aware of one thing: the destination page uses the same response stream that was created by the original page, and therefore the hidden _VIEWSTATE field of the original page ends up on the second page. This causes the ASP.NET machine authentication check (MAC) to assume that the ViewState of the new page has been tampered with. Therefore, when you choose to preserve the form and query string collection of the original page, you must set the EnableViewStateMac attribute of the Page directive to False for the destination page.

Server.Execute

The Server.Execute method allows the current ASPX page to execute a specified ASPX page on the same web server. After the specified ASPX page is executed, the control transfers back to the original page from which the Server.Execute method was called. This technique of page navigation is analogous to making a function call to an ASPX page. The called ASPX page has access to the form and query string collections of the calling page, and thus you need to set the EnableViewStateMac attribute of the Page directive to False on the executed page.

By default, the output of the executed page is added to the current response stream. This method also has an overloaded version in which the output of the redirected page can be fetched in a TextWriter object (or one of its children, such as a StringWriter object) instead of added directly to the response stream. This helps you to control where to place the output in the original page.

To see how this works, create a Web Form in a test ASP.NET application and place a Button control (Button1) and a Literal control (Literal1) on the Web Form. Switch to code view and add an Imports statement for the System.IO namespace. Then add code to execute when the user clicks the button:

Private Sub Button1_Click( _
    ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
        Handles Button1.Click
        Dim sw As StringWriter = New StringWriter()
        Server.Execute("WebForm2.aspx", sw)
        Literal1.Text = sw.ToString()
End Sub

Now create a second Web Form in the same application, WebForm2.aspx. Switch to the HTML view of this second Web Form and modify its Page directive to disable ViewState checking:

<%@ Page Language="vb" AutoEventWireup="false" Codebehind="WebForm2.aspx.vb"
  Inherits="Navigate.WebForm2" EnableViewStateMac="false"%>

Switch back to design view and add some controls to the second Web Form. Now set the first Web Form as the default page and start the application. Click the button, and the controls from WebForm2 will be displayed in the area of WebForm1 where you placed the Literal control, as shown in Figure 1. You'll note from the URL and page title that the browser is still displaying WebForm1.

Figure 1: A page in the browser composed by using Server.Execute to combine two source files.

There's one more thing to be aware of when you use the Server.Transfer or Server.Execute methods to navigate: the ultimate page may not be valid HTML. That's because the response to the client will contain multiple <html> and <body> tags, among other tags. Internet Explorer seems to tolerate this situation just fine, but you may want to test the results carefully if your users prefer a different browser.

Decisions, Decisions

So, given these choices for navigating from page to page, how do you select the appropriate one for your application? Here are some things to think about:

• Hyperlinks are appropriate when you want the end user to control when navigation is performed, or to choose where to go.
• To control the user's destination, but let them decide when to get there, use a Web Server HyperLink control whose NavigateUrl property is dynamically set.
• Use Response.Redirect to connect to resources outside of the web server where your page is hosted.
• Use Response.Redirect to connect to non-ASPX resources such as HTML pages.
• Use Response.Redirect if you need to preserve a query string as an explicit part of the URL.
• When you want to transfer control to an ASPX page residing on the same web server, you should use Server.Transfer instead of Response.Redirect because Server.Transfer will avoid the unnecessary round trip and provide better performance and a better user experience.
• To capture the output from an ASPX page and display it at a specified location on another ASPX page, use Server.Execute.
• If valid HTML output is essential, use Response.Redirect instead of either the Server.Transfer or Server.Execute methods.

Mike Gunderloy is the lead developer for Larkware and author of numerous books and articles on programming topics.

How to make a self-adapting size iframe

I didn't test the code on any browser yet, so if you tried and found any issue please leave a comment here. THX

<iframe id="iFrame1" name="iFrame1" width="100%" 
onload="this.height=iFrame1.document.body.scrollHeight" frameborder="0" src="index.htm">
</iframe>

How to create WCF service manually

This article will show you how to create a WCF service by hand instead of the VS IDE. The reason of doing so is we can get rid of all the rubbish code created by VS and also it will help us understand more the infrastructure of WCF skills.

To build a WCF service manually we will create 5 assemblies:
1, Contract
2, Service
3, Host
4, ClientProxy
5, Client/WebClient

The Contract assembly (a class library) is the core of a particular WCF service. All the other 4 assemblies need a reference to this Contract.dll. The Contract assembly need a reference to System.ServiceModel so it can use all the related attributes: ServiceContract, OperationContract etc etc.

The Service assembly (a class library) includes the implementation of all the Contract Interfaces. You no need reference to System.ServiceModel for this assembly.

Now we are going to finish our first WCF service. To do so we need create a host. The Host assembly (a console app) will reference to Contract, Service, System.ServiceModel dlls and will need a Service configuration file. Below is a very sample config including two endpoints (using net.tcp and http proxy)

//Config file
<configuration>
  <system.serviceModel>
    <services>
      <service name="WcfTraining.Service.MyFirstService">
        <endpoint address="net.tcp://localhost:4002/MyFirstService"
                  binding="netTcpBinding"
                  contract="WcfTraining.Service.IHelloService"></endpoint>
        <endpoint address="http://localhost:9002/MyFirstService"
                          binding="wsHttpBinding"
                          contract="WcfTraining.Service.IHelloService"></endpoint>
      </service>
    </services>
  </system.serviceModel>
</configuration>


//Code behind
ServiceHost serviceHost = new ServiceHost(typeof(MyFirstService), 
        new Uri("net.tcp://localhost:9002/"));
serviceHost.Open();

Now you can run this Host app and a WCF service is online immediately. How easy it is. Warming: the <configSections> tag has to be always the first tag in the configure file.

Note: the second param of the ServiceHost method IMO is used to test if the Uri address is available. It could be any valid Uri address but if it is not exited in your endpoint list then it means nothing to client.

When the service is runing it is time to build our client. The first thing we need do is build a ClientProxy assembly which is a class library referenced the Contract and System.ServiceModel assemblies. Inside we simply implement the Contract Interface and inherit a generic class CProxy<Interface> which supply a ChannelFactory instance, which is used to communicate with the service. For example if we have a service named GetMessage and we are inheriting from System.ServiceModel’s inner Proxy ClientBase<> then the code will simply be:

    public class Proxy : ClientBase<IHelloService>, IHelloService
    {
        public string GetMessage(string name)
        {
            return Channel.GetMessage(name);
        }
    }

We are almost there now. The final is build our own client which could be a win app, console app or web app. The client need reference the ClientProxy, Contract and System.SerivceModel assemblies. And also the Client need a config file to tell where the service is runing. Please remembet there should be only one endpoint inside the client config file. Below is a client config sample.

  <system.serviceModel>
    <client>
      <endpoint address="net.tcp://localhost:4002/MyFirstService"
                binding="netTcpBinding"
                contract="WcfTraining.Service.IHelloService" />
    </client>
  </system.serviceModel>

Remember the abc in the config file: address, binding and Contract. Inside the Client class, simply create a instance of ClientProxy and directly call any service method you want. All Done.

Proxy proxy = new Proxy();
MessageBox.Show(proxy.GetMessage(textBox1.Text));