Star-TED Lab Specs

# CPSC1517 Project Specs

StarTED Database - A simple database for a post-secondary school.

# Overview

This document outlines the marking guide and general requirements for the lab. Each student is expected to select one scenario from the catalogue of scenarios developed for the StarTED database. Your instructor will provided information on how students will select their scenario. For the selected scenario, the student must complete two fully-functional forms:

  • CRUD – Single item Create/Read/Update/Delete.
  • Query – GridView Lookup with ObjectDataSource controls.

Your instructor will provide information on

  • Where to access the catalogue of scenarios
  • Where to obtain the database
  • Any additional information on submitting/demonstrating the lab

# The Deliverables

A detailed marking guide is provided at the end of this document. For this lab, the student must demonstrate their working Visual Studio solution in several deliverables (listed below). Each demonstration of the student's scenario must be presented to the instructor in-class in order to gain the marks for that deliverable. An additional deliverable will be a electronic submission of your planning for the CRUD form. The deliverable requirements for evaluation have been outlined in the Marking Guides of this document.

Tentative Due Dates

These dates may change for your class. In all cases, please check with your instructor for the correct due dates.

Your instructor will provide specific dates on each deliverable.

Late labs or failure to demonstrate in-class will receive a mark of zero for each affected part.

# The Visual Studio Solution

Your solution must be a client-server solution consisting of multiple projects as outlined in the course. The Presentation Layer portion is to be an ASP.NET web application. The BLL and DAL portions of the system are to be placed in a separate class library project. Likewise, the entities of the system must be in their own separate class library project.

# The StarTED Database

The database supplied for this lab is an SQL Server database named "StarTED". The following is a sample of the connection string that may be used for the Presentation Layer. Retain your default connection string when creating the connection string webconfig file.

  <connectionStrings>
    <add name="StarTEDDb"
         connectionString="Data Source=.;Initial Catalog=StarTED;Integrated Security=True"
         providerName="System.Data.SqlClient" />
  </connectionStrings>

# The Forms

There are two web forms for the core functionality of this project (described below). You must name the forms Query.aspx and CRUD.aspx. In addition, you must have a Default.aspx web form at the root of your web application that acts as the lab documentation for your selected scenario. All of these forms must share the same Master Page, which must provide navigation among all the pages in your web application.

# Master Page

Your master page must contain the following elements:

  • Site Navigation – Links to all the pages in the web application (use the Menu control).
  • Scenario Title – The number and name of the scenario (e.g.: G1 – Reservations by Group).
  • Student Name – Your first and last name.

# Default Page

Your default (home) page must contain the following elements (each with their own heading):

  • Form Description – A brief description of each form in the solution, identifying the name of the form and its purpose, along with any unique constraints or characteristics of the form's behaviour.
  • Known Bugs – A bulleted list of all the known bugs and incomplete portions of the lab.
  • Entity Relationship Diagram - The ERD diagram (from the lab selection) of your selected scenario.
  • Class Diagrams – Class Diagram images of the BLL and Entities, showing the full method/property signatures of each class.
  • Stored Procedures – A bulleted list of all the stored procedures used in your project.

# CRUD – Single Item CRUD

This form is similar to the cumulative results of concepts demonstrated in the Data Access CRUD topics and exercises. In this form, the student must provide a means to

  • Lookup and display a single row of data from a table
  • Insert new rows of data into a table
  • Update an existing row of data in a table
  • Delete (or mark as inactive/not current) a row of data in a table

# Handling Large Data Sets

For most of the scenarios, you will need to perform your look up in two steps. The reason for this is because there are far too many rows of data to put in a single drop-down list. For example, with thousands of Students in the database, it is impractical to fill a drop-down and expect a user to find the student they wish to edit. In these situations, a two-step selection process makes the form more managable by the user. The filter search sql procedures have been written to produce an error if too many records would be returned.

  1. First, gather user input to send to the supplied stored procedure so as to produce a "short-list" of items to select from. You can display this short list in either a DropDownList, GridView or RadioButtonList control.
  2. The second step is where the user can select a single item in the short list to edit.

Also note that many of the scenarios will require you to have this two-stage selection process not only for choosing the row of data to edit, but also for selecting a related item as the foreign-key reference for the entity you are editing.

# Other Considerations

Depending on the scenario and the table, the Delete functionality may not be a physical removal of a row of data. This is because some tables have triggers or other constraints that prevent the removal of existing rows. In these cases where a row cannot be deleted (excluding foreign key constraints preventing removal), the table will have some means of flagging the row as being inactive or not current.

For example, in the Employee table, a foreign key constraint prevents any rows from being deleted. However, that table has a nullable column called "ReleaseDate" which can be set to indicate that the person is not currently employed. For advice on how to deal with these situations, please consult your instructor.

# Query – ObjectDataSource Search & Display with a GridView

This form is similar to the concepts demonstrated in the Data Bound Controls topic and exercise. In this form, the student must use a GridView to display multiple rows of data. All fields of the displayed entity must be used, unless otherwise specified in your scenario. The GridView must implement paging, with the page size being set to between 10 and 25 rows per page (as appropriate for your scenario).

For the GridView control, all foreign key information must be displayed/editiable via a DropDownList that displays appropriate information to the user while representing the value for the foreign key.

The controls in this form must be populated using ObjectDataSource controls only (no code-behind can be used to populate the forms).

BLL methods used by this form must be exposed for discovery to the Object Data Source: Configure Data Source wizard.

← Lab Selection →