ABOUT THE WORSHIP DATABASE PROJECT

Don Milnor

(This document, more or less, in Word format, can be accessed here.)

To Whom It May Concern,

I am posting some information about a project I've been working on, my own idea, and not for an employer. Thus, I can share the code with prospective employers, without having to worry about lawyers coming after me, etc.

It has two major parts:

  • An application in C# to import the data.
  • A web-based interface in Javascript to access the data from wherever, and reference and edit content.

    Web-based interface in Javascript

    The web interface may be accessed at:

    http://milnoid.brinkster.net/worship/Default.asp?Demo=Yes

    This accesses a demo version of the database, with names changed. Its code is available as well, in plain text format (original file has an .asp suffix), and PDF format to see the color coding easily.

    Currently, the following functions are available:

  • Retrieving a worship service by date (goes back over 10 years)
  • Songbook maintenance (add, edit and delete songbooks referenced)
  • Changing a user's own password
  • Admin functions (currently only function is user record maintenance)
  • Listing usage of a particular song (every time a certain song has been used starting with the most recent)
  • Editing song information

    The import program described below imported the songs themselves, along with possibly page number and key. But these may be modified in this function, plus alternate song titles, a description, page numbers in alternate books, and lyrics, may be added, modified or deleted.

    Desktop importing application in C#

    (This actually came first.) For over 10 years, I have been making lists every week in Word for our church's Sunday morning worship, who does what when, and what songs are used. Three examples (Word .doc files) are included:
  • 1st
  • 2nd
  • 3rd

    I wrote an application in C# to parse these documents and extract what was done, what songs were used, etc. and put them in various tables. This involves lots of data validation, and as I was going, I found the data wasn't quite as consistent as I had hoped for; I needed to code around some such things. But for most part, they are, even though I didn't have any plans for an application to parse the data when I started writing them this way. I'm just dealing with what's there, as we often need to do in the IT world. I'm storing the data in Access rather than SQL, because I already have Access and don't have to buy SQL. (SQL otherwise would be a better choice.) Again, dealing with what's there, or not there, and cost factors.

    It has to figure things out like: Is the song listed in the Songs table already? If so, get the ID number. If not, add it and get the ID number. Put that ID number in the WorshipActivityInstances table: 1 record for each worship activity for each worship, keeping track of who leads what, and in what order, so some day I can write something to print out who did what and when on a particular day (basically reproduce the list for any given worship). The same goes for the person leading that part of worship. Is the person there? If not, put them in the table. Either way, get their ID number for the record to be added to WorshipActivityInstances.

    I have since run through over 500 such files, putting the information into the .mdb (Access) file currently on this website. I went through the songs manually, finding multiple entries for the same song, spelled differently, and making them consistent. (The screen prints below show the data after entering just 3 files.)

    The user interface (screen prints below) prompts the user for the location of the Access file, and either a Word document, or a text file with a list of paths to multiple Word documents. A line on the screen updates the user with what line it's on (usually about 20 per document), and which file ("File 17 of 45", etc.).

    Available is the code in 2 .cs files renamed .txt (1, 2, they can be opened with Notepad, plain text), and the same thing in 2 .pdf files (1, 2, you can see color coding without having anything special to read it), in case anyone's interested.

    Some screen prints of the interface, and then table definitions:

    The interface took a good guess above, and in this case, it was correct.

    The tables below, after adding this information (just the 3 input files): I manually entered the information in Users, WorshipActivities and SongBooks. There's nothing in SongCategories yet.

    The entries in tables Persons, Songs, and WorshipActivityInstances were entered by this application. Except I manually changed the names in the Persons table to ficticious ones, in the screen print below, and in the demo database.

    Please let me know if you would like any further information about this project, or better yet, if you have any interest in hiring me as a software developer with your organization.

    Don Milnor
    Return to my resume page