Beginning ASP.NET 2

Setup

Figure B-22

Please note that while Figure B-22 is seemingly identical to Figure B-21, the Address lines reveals a small difference. If you are running your site on Cassini (the free web server with VWD), you will get the following line (potentially with a different number): http://localhost:1231/WroxUnited.

This indicates that the web server is running on port 1231. Cassini will arbitrarily assign a port number in the URL. If you are running the web site on IIS, then you see the following line: http://localhost/ WroxUnited.

IIS by default runs on port 80, and this doesn’t need to be specified in the URL.

Occasionally, if port 80 is taken by another process, IIS will default to http://localhost:8080, or you might have to specify it yourself if you get an error message saying Unexpected error 0x8ffe2740 occurred.

This means that another application is using port 80. To alter this, you need to start the IIS manager from Administrative Tools in the Control Panel, right-click the Default Web site in the left panel, and select Properties. From the Web Site tab, change the number there from 80 to 8080, or if 8080 is taken then 8081 or the first one free above that number.

669

Appendix B

Troubleshooting

Unlike with previous versions of ASP and ASP.NET there are no specific gotchas in the installation process. If you encounter a problem go to http://forums.asp.net and check to see if your problem is answered there.

670

C

Wrox United Database

Design

Throughout this book we’ve presented examples based on the fictional Wrox United soccer team web site. The application relies on a SQL Server database, supplied with the code downloads for this book (available at www.wrox.com). This database stores details of the players in the team, fixtures and results, news items, orders from the shop, and so on.

This appendix is not intended to provide a thorough overview of database design principles, and as such, I recommend reading Wrox’s Beginning Database Design.

The database schema looks like Figure C-1.

Figure C-1

Appendix C

This diagram illustrates the tables that exist within the database, and the relationships between those tables. For example, players score goals, goals are scored at fixtures, match reports are written about specific fixtures, and so on. Many tables relate to other tables in the database, but equally, there are some tables that stand on their own; for example, the News table, which stores news articles. This table doesn’t link to data stored in any other table. Notice also that the Orders, Products, and OrderLines tables are separate from the rest of the database — these tables are used to store data relating to orders from the Wrox United shop.

This appendix walks through the structure of each of the tables in the database and describes the relationships between them.

Players and Matches

The players on the Wrox United team are involved in many fixtures, and several related tables in the database store related data for matches. Take a look at these tables first.

The Players Table

The structure of the Players table is as follows:

This table is typical of all database tables in that it has the following:

A primary key field that uniquely identifies each row in the database.

Fields designed to store textual data about each player (in varchar fields).

Fields that store date and time information.

Flags indicating whether or not different fields require values.

In this table, the primary key is the PlayerID field, which stores numeric values (integers) that are unique to each player in the database. This field, along with the FirstName and LastName fields, is marked as not allowing null values; in other words, if you enter a row of data in the table, you must

672

Wrox United Database Design

enter values for each of these fields. However, the PlayerID field will be filled with an auto-generated number for you automatically (due to the way it is configured), so the only data you must enter when you create a new row is the full name of the new player. The remaining information describing the player is optional. You don’t have to specify which position the player occupies, and you don’t have to specify when he or she joined.

Note that a varchar field is a field that stores character data of varying length. The number in brackets is the maximum number of characters that can be stored in that field. If the field contains less than the maximum length, it occupies less space in the database. A char field, by comparison, always takes up the same size in the database, no matter how much of the available space is filled with data.

Figure C-2 shows an example of some data from the Players table.

Figure C-2

This screenshot comes straight from Visual Web Developer; you can right-click any database table in the Database Explorer and select Show Table Data to try this out for yourself.

The Goals Table

The Goals table relates directly to the Players table, because players score goals during a match. Here’s the structure of the Goals table:

673

Appendix C

Notice that one of the fields in this table is the PlayerID field, which will store an integer value corresponding to the ID of one of the players in the Players table, so if Dave Dickenson scored the first-ever goal for Wrox United, the goal in the table with GoalID of 1 will have a PlayerID of 4. Dave could later score another goal for Wrox United, so another record in the Goal table would be created with another unique value for GoalID, but with the same PlayerID. This type of field is called a foreign key because it relates directly to a primary key in another table.

There is another field in the Goals table for storing ID values, which is the FixtureID field. This links each goal to a particular fixture. Because players could score many goals at a single fixture, the relationship between the Fixtures table and the Goals table is similar to that of the Players table and the Goals table.

This sort of relationship — where one fixture can contain many goals, or where one player could score many goals — is known as a one-to-many relationship.

The Fixtures Table

The Fixtures table is structured as follows:

For each match played by the Wrox United team, there is an entry in the Fixtures table. Because fixtures can be arranged several months in advance, the fixture date has to be entered as soon as the fixture is arranged, and the opponents have to be entered. The number of goals scored can be entered later once the match has been played.

674

Wrox United Database Design

The MatchReports Table

After each match has taken place, it’s up to the reporters to write up the details of the match so that fans can read all about it later. These reports are stored in the MatchReports table, which is structured like this:

This table also links to the Fixtures table by including a FixtureID field in this table, linking a match report to a specific fixture. The MemberName field stores the name of the reporter.

The Gallery Table

The Gallery table is used to store details of pictures uploaded by fan club members. Here are the fields defined in this table:

Each picture can relate to a specific fixture (notice the FixtureID field); however, because this field allows the use of null values, this implies that pictures do not necessarily have to relate to fixtures.

Standalone Tables

The two standalone tables in the database are the Opponents table and the News table.

The Opponents Table

The Opponents table stands on its own in the database, and is defined as follows:

675

Appendix C

The reason the Opponents table is on its own is a bit unfortunate, but the opposing team may decide to change its name at some point in the future, which would change the name of all fixtures that Wrox United played against them in the past if they were related. By keeping the tables separate, and only using a name for each team, the name of the opponent in any particular match is preserved.

This table can be updated with results of matches to maintain a tally of how well the Wrox United team is performing in the league.

The News Table

The News table contains all of the stories from the front page of the Wrox United site:

Notice that each news item requires that a date be entered for each story, so that a story can remain hidden until a certain date has passed.

676

Wrox United Database Design

Wrox United Store Tables

The online shopping experience on the Wrox United site relies on data stored in three tables: the Orders table, the Products table, and the OrderLines table. These tables are heavily reliant on each other, so this section considers these now.

The Orders Table

The Orders table contains a unique ID containing the main order details for an order:

In this table, you’ll notice that most of the fields are marked as mandatory (not allowing null values). This highlights the fact that orders must have full address details before an order can be fulfilled. A couple of less familiar field types are in here too. The nchar data type will always take up 10 characters space in the database, and the n in the name indicates that the data stored could contain Unicode characters. The other unfamiliar data type is money, which (as the name implies) can be used to store monetary values.

Notice that there are no details in this table about which products have been bought in a particular order; this information is stored in the OrderLines table.

The OrderLines Table

This table links the Products table to the Orders table, indicating which items have been bought in a particular order:

677

Appendix C

Because an order can contain one or many products, there is a foreign key link here to the Products table. However, because many different orders can be for the same product, there is also a foreign key link here to the Orders table. This means that an individual line in this table stores details of one item, and one order number. If you order more than one of a specific product, the Quantity is increased for the order line, but you won’t end up with a new OrderLineID.

The relationship between the Orders table and the Products table is a many-to-many relationship. In this situation, there has to be a central table that has one-to-many relationships to both tables, and this is called the Join table.

The Products Table

The Products table contains details of all of the products that can be bought from the shop:

This simple table provides data about products, and is used both when browsing the shop and when buying items from the shop.

678