Monday, July 24, 2006

How to store the database connection in webconfig file in ASP.NET

ASP.NET provides a configuration system we can use to keep our applications flexible at runtime. In this article we will examine some tips and best practices for using the configuration system for the best results.

The element of a web.config file is a place to store connection strings, server names, file paths, and other miscellaneous settings needed by an application to perform work. The items inside appSettings are items that need to be configurable depending upon the environment, for instance, any database connection strings will change as you move your application from a testing and staging server into production.

As an example, let’s examine this appSetting entry in the web.config file to hold our connection string:

<add key="ConnectionInfo" value="Data Source=Annapurna;Initial Catalog=ISClass;User Id=isclass;Password=isclass">

To read the key we use the ConfigurationSettings class from the System.Configuration namespace, as shown below.

12 private void Page_Load(object sender, EventArgs e)

13 {

14 string connectionInfo = ConfigurationSettings.AppSettings["ConnectionInfo"];

15 using(SqlConnection connection = new SqlConnection(connectionInfo))

16 {

17 connection.Open();


19 // perform work with connection


21 }

22 }

Some applications will duplicate these lines of code in many places. If we think about how the above code will evolve over time, we might see a handful of weaknesses. First, we have a hard coded string in place to fetch connection information from the web.config. Hard coded strings can be easy to mistype and difficult to track down if the key ever changes. Secondly, the code will tie us forever to the appSettings section of the web.config file. Although web.config is designed for just such a setting, we might find in the future that we need to pull configuration settings from a database, or change a setting from being application-wide to being a per-user configuration item kept in the Session or in a cookie.


Let’s abstract away the source of the connection string using a class with a static property.

1 using System.Configuration;


3 namespace aspnet.config

4 {

5 public class Configuration

6 {

7 public static string ConnectionInfo

8 {

9 get

10 {

11 return ConfigurationSettings.AppSettings["ConnectionInfo"];

12 }


14 }

15 }

16 }

Now our Page_Load method looks like the following.

11 private void Page_Load(object sender, EventArgs e)

12 {

13 using(SqlConnection connection = new SqlConnection(Configuration.ConnectionInfo))

14 {

15 connection.Open();


17 // perform work with connection


19 }

20 }

The changes we made to the above code were relatively small - but powerful. Now the Page_Load function doesn’t know where the connection string comes from. We could easily change the ConnectionInfo property to retrieve the string from a different source without modifying any other code in the application. We also no longer have to remember the key string and hard code the string at various points in the application. Instead, we can utilize Visual Studio Intellisense when accessing the Configuration class to find the setting we need. The key value only appears once – inside the ConnectionInfo property – so we could again change the key name in the web.config and have only one line of code to update.

Of course this approach only works if all of the code in the application goes to the Configuration class instead of directly to web.config to retrieve settings. For each appSetting entry added to web.config we would add a corresponding property to the Configuration class.

Another advantage to this approach becomes apparent if we have an application setting that is not a string, but a date, integer, or other primitive type. In this case we could have the corresponding Configuration property parse the string from the web.config file and return the appropriate type.

You’ll notice we provided a read-only property for ConnectionInfo. The web.config file is not designed for constant updates. When an ASP.NET application launches a watch is put on the web.config file. ASP.NET will detect if the web.config changes while the application is running. When ASP.NET detects a change it will spin up a new version of the application with the new settings in effect. Any in process information, such as data kept in Session, Application, and Cache will be lost (assuming session state is InProc and not using a state server or database).

Friday, July 14, 2006

How to Enter Symbols into Window Forms or ASP.NET web pages

Letters with Accents

This list is organized by Accent type. To determine the appropriate numeric code, match the accent with the vowel.

Accent A E I O U Y

Grave (Lower) à

Acute (Lower) á

Circumflex (Lower) â

-- Ñ
Tilde (Lower) ã
-- ñ
Umlaut (Lower) ä

Example: To input the acute a á (0225), hold down the ALT key, type 0225 on the numeric keypad, then release the ALT key.

If you are having problems inputting these codes, please review the instructions for using the codes at the bottom of this Web page.

Other Foreign Characters

These include special punctuation and unique consonant and vowel symbols.

Upside-down exclamation mark 0161
¿ Upside-down question mark 0191
Ç, ç French C cedille (caps/lowecase) 0199
Œ,œ O-E ligature (caps/lowecase) 0140
ß German Sharp/Double S 0223
Ø,ø Nordic O slash (caps/lowecase) 0216
Å,å Nordic A ring (caps/lowecase), Angstrom sign 0197
Æ, æ A-E ligature (caps/lowecase) 0198
Þ, þ Icelandic/Old English Thorn (caps/lowecase) 0222
Ð, ð Icelandic/Old English Eth (caps/lowecase) 0208
« » Spanish/French quotation marks 0187

Currency Symbols

¢ Cent sign 0162
£ British Pound 0163
Euro currency 0128
¥ Japanese Yen 0165
ƒ Dutch Florin 0131
¤ Generic currency symbol 0164

Math Symbols

÷ Division sign 0247
° Degree symbol 0176
¬ Not symbol 0172
± Plus/minus 0177
µ Micro 0181

Other Punctuation

These incude copyright symbols and special section marks.

© Copyright symbol 0169
® Registered symbol 0174
Trademark 0153
List Dot 0149
§ Section Symbol 0167
en-dash 0150
em-dash 0151
Paragraph Symbol 0182

Using the Codes

Windows assigns a numeric code to different accented letters, other foreign characters and special mathematical symbols. For instance the code for lower case á is 0225, and the code for capital Á is 0193. The ALT key input is used to manually insert these letters and symbols by calling the numeric code assigned to them.

To use the codes:

  1. Place your cursor in the location where you wish to insert a special character.
  2. Activate the numeric key pad on the right of the keyboard by pressing Num Lock (upper right of keyboard). The Num Lock light on the keyboard will indicate that the numeric key pad is on.

    NOTE: You must use the numeric key pad; if you use the number keys on the top of the keyboard, the characters will not appear. If you are on a laptop or computer without a separate numeric keypad, other methods are recommended.
  3. While pressing down the ALT key, type the four-digit code on the numeric key pad at the right edge of the keyboard. The codes are "case sensitive." For instance, the code for lower-case á is ALT+0225, but capital Á is ALT+0193.

    NOTE: If you have the International keyboard activated, you will only be able to input codes with the ALT key on the left side of the keyboard.
  4. Release the ALT key. The character will appear when the ALT key is released.

    NOTE: You must include the initial zero in the code. For example to insert á (0225) you must type ALT+0225, NOT ALT+225.

Wednesday, July 12, 2006

How do I enter a null date into the database?

Make sure that the System.Data.Namespace is included.

include System.Data.SqlType;

In the command parameters to be parsed into database, use SqlDateTime.Null:

public void InsertDateOfBirth(string Date1){
SqlConnection cn = new SqlConnection();
string sqlstring = "Insert into Database1 values (@birthday)";
SqlCommand cmd = new SqlCommand(sqlstring, cn);
cmd.Parameters.Add("@birthday", SqlDbType.DateTime);
cmd.Parameters["@birthday"].Value = DateTime.Parse(Date1);
catch (Exception er)
cmd.Parmeters["@birthday"].Value = SqlDateTime.null;
catch (SqlException sqlerror)
catch (Exception er1)

Tuesday, July 04, 2006

Common Project Management Pitfalls part 1

This is a multi-part article about common project management pitfalls.

Why is it that for most IT Projects, it is often difficult to meet the projected datelines, and deliver the system within time, budget and specification constraits? Indeed, as any project manager who is worth their weight in salt can testify, IT projects seldom, if ever meets the dateline, budge and specification. In fact, a study by the Standish Group Report (1995) shows that some 83.8% of projects are either challenged (the project is completed, but over-budgeted, over time-estimated or offers fewer features and functions than originally specified) or impaired (the project is canceled at some point during the development cycle). This has lead many project managers to dispair when things failed to go their way. What are the common causes of this problem?

Project objectives not fully specified / Poor Communications

Surprisingly, a study by Pete Marwick (1998) found that 51% of projects planning fails because the project objectives is not fully specified and poor communication between the client and the system analyst. There are many reasons why the project objectives are not fully specified or well-detailed. Below list some of the common pitfalls that lead to project failure under this catergory.
  • Lack of Project Methodology to plan the deliverables
    Project Methodology refers to the way in which the project is done. Most software development projects follow a project life cycle - the collection of project phases. A Software Development Life Cycle is a framework for describing the phases involved in developing and maintaining information systems. It provides a consistent and effective approach for undertaking projects. Without a clear Project Methodology or Software Development Life Cycle, it is difficult to impossible to plan for a job.

    A clear framework or Software Development Life Cycle model to follow makes it easy for programmers and IT consultants to understand the job scope, and what the deliverables are at each stage. For instance, at the Requirements Specification phases in the waterfall model, the deliverables are all the requirements of the system, sample user interfaces, and the flow of events (sequence diagrams, event diagrams or flowcharts). With a clearly defined project objectives signed by both parties, it makes it easier to agree on the project objectives. Without doubt, one of the first objective of any solid project management plan is to plan for and agree on the project requirements.

  • Analyst failed to understand client's requirements and understand client's needs.
    It is my opinion that the planning and agreeing on the project requirements phases is the most important part of the project life cycle. Finding out why the client wants a system, what type of system he is looking for, what type of software/hardware he needs is one of the most critical stages in the software development phases. By understanding the needs of your clients and putting it in writing, you can constantly review if the design of the UI meets their needs. Gathering information such as samples of previous work, documentations, interviews, surveys and other information prior to starting the work is essential to confirm what you will be doing, and scope of the project. Many project manager failed to see this as the most important part of the project, and allocated too little time to this phase. How are you going to plan and propose an effective system for your clients if you do not understand what is required?

    Do allow at least 1 week to ensure that you understand all the documentations and process involved in the system, and the job scope. Only and only then can you begin to plan how long the project will take.

    One good way of ensuring that you understand your client's business process is to draft a flowchart of the sequence of diagrams for each process. By doing so, you are confirming what you think is the way the process work against what the process actually work. Most clients happily point out your mistakes, so present your findings and ask them to clarify any doubtful points. Once there are no more obstacles, get your client to sign the documentation confirming that is the actual flow of events.

  • User Design is not what the clients wants...

    Once the scope of project is confirmed, the next most important item is to draft the user interface. Those who just jump straight into programming without a drafting the user interface is in for a lot of re-coding work - especially when your user interface is flatly rejected by the client later on. Your user interface speaks volume of what you think what the clients want and need against what he actually needs. By providing a good user interface, both of you are agreeing on the scope of the work, and how the data should be presented.
    The client should sign off the user interfaces to show that he accepted the UI design.

  • Failure to check with client the actual data stored

    The next most essential phase of the project is the design phases. Before you go on to conduct class diagrams, sequence diagrams etc, the first thing you need to do is to design the database first. The database should take in account all fields in the UI design. The primary key, a description of key flags (e.g. status: p = pending, c = completed, a = approved, r= rejected), and any foreign keys should be identified. Each table should have a short description of what information it stores. Finally relationship diagram should be drawn for easy referencing. By confirming with your client what type data are actually stored and can be retrieved, it helps to prevent problems later on, especially when they need some more data that is not stored (believe me, this is darn common).

  • Planning the Project Timeline.

    Once all documentations above has been signed off, only and only then can the project datelines, deliverables and budget be planned and controlled with any good chance of completing the project on time and on budget, with all features and functions as initially specified. A common mistake many new project manager makes is to break down the work structure accordingly to phases in the Software Development Lifecycle. While this provides a good overview of what is to be done, it is at best, fairly inaccurate. The project manager should instead further breakdown the work into sections, and allow some time for each sections. For instance, the work involved requires some 30 User Interfaces screen. Planning 1-2 days for each UI for a 3 tier development for each staff assigned helps to paint a more accurate picture of the time required for documentation and programming.

    The client should be informed of the project plan and sign off the agreement on datelines of the project. Also, it is a good communication practice to inform and update the client on project progress status on a weekly basis.

  • Documentation and Designing the Sequences Diagram, Class Diagram, Event Diagrams

    At this point, the next key step is to draft all the documentation. The sequence diagram, class diagram and event diagrams should be planned and documented prior to coding. By documenting how each class is related to one another, and planning for a 3 tier architecture, you are ensuring reusibility of class, and saving time on programming.
    Also, by doing this, you are insuring yourself against changes in business logic or database structure. When such change are required, they can be implemented with minimum effort by identifying which classes are affected by the changes.

    Many programmers hate this step and in some companies, this step is often left until all the programming has been done.

  • Frequent changes to the project specification

    Let's face it, the client is human too, and human has a tendency to change their mind. The worse clients are those who have no clue to what they want and frequently change their mind - because once the system is coded and development is under way, the system is often inflexible and the changes to the coding or database are often tedious and time-consuming. This is especially so when a small change in code or database can lead to all sorts of bugs can pop out elsewhere in the program, and tons of re-editing the documentations is required. By getting the work flow, user interface and database signed off, you are protecting yourself against any changes to project specifications.

    Should your client insist on the changes after all the specifications have been signed off - it is best to evaluate if the change can be implemented with minimum inconvenience. This is where all the documentations come in handy - review the documentation to see if the changes will affect several classes or isolated to one or two classes. If the changes can be implemented with minimum effort, it should be incorporated into the system - building a good relationship with a client is important. However, if the changes required is medium to heavy in effort, it is often required to politely but firmly inform the client that these changes are not in the requirements, as per the signed off UI, database and project plan, but you can implement them for an added fee - it is not good business to engage in a losing preposition. Also, there will be a delay in schedule to accommodate the changes required. Often the increase in budget and delay in delivering the system will make the client think twice if the changes to be implemented are essential or just a whim on his side. Even if the changes is to be incorporated into the system, there is some benefit for your organization in terms of increased timeline and profits.
In the next part of this series, I will cover the common pitfalls of bad planning and estimating.

Monday, July 03, 2006

Sun Java IDE

Sun Java developers new IDE (Integrated Developer Environment) is available for FREE at :)

It automatically creates class diagrams, UML, sequence diagrams, with intellisense (Java Version) + UI design and best of all, it is free! It comes with a neat, easy to use UI for developing JSP, EJB code quickly and effectively.

Saturday, July 01, 2006

Connection Strings

These connection strings are for .NET programming environment which can be connected to a wide variety of database. Below are some of most common connection strings

MSSQL Server
  • SQLServer
    "Data Source=MSSQLServerName;Initial Catalog=Northwind;User Id=id;Password=password;"
  • OleDbServer
    "Provider=sqloledb;Data Source=MSSQLServerName;Initial Catalog=Northwind;User Id=id;Password=password;"
MS Access
  • Standard
    "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\somepath\mydb.mdb;User Id=admin;Password=;"

  • With Password
    "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\somepath\mydb.mdb;Jet OLEDB:Database Password=MyDbPassword;
  • ODBC
    "Driver={Microsoft ODBC for Oracle};; Uid=Username;Pwd=password;"
  • OLE DB
    "Data Source=MyOracleDB;User Id=username;Password=passwd;Integrated Security=no;"
  • OLE DB
    "Provider=MySQLProv;Data Source=mydb;User Id=UserName;Password=asdasd;"