From Database to Web Site: Active Server Pages and the Construction of a Web Interface to a Historical Relational Database

G. K. Peatling and Chris Baggs

The paper summarizes logistical and technical procedures involved in the creation of a web interface using ASP scripts to a Microsoft Access 2000 database derived from historical source documents. It evaluates the possibility of the wider application of this method of disseminating historical research findings. The construction of such web sites certainly can prove an important option for publicizing historical resources to the general advantage of scholarship. However, this strategy is by no means appropriate to every similar historical project, and it is advisable to undertake an informed evaluation of the advantages and pitfalls of such a procedure before implementing it.

.01. INTRODUCTION

In November 2000, an article describing aspects of the project "British public library annual reports, 1850-1918" appeared in the Journal of the Association for History and Computing [ [1] ]. This article described steps taken in the design of a database of information derived from a selection of British public library annual reports, largely held at the Thomas Parry Library at the University of Wales Aberystwyth (UWA) in the United Kingdom. Since the publication of this article, the project has moved on several paces. Most significantly, a web interface to the database now exists, and is freely accessible [ [2] ].

The purpose of this article is to summarize the logistical and technical procedures involved in creating this web interface to the database and to evaluate the possibility of the wider application of this method of disseminating historical research findings. Increasingly, historians construct databases to facilitate their own research. Whether or not such databases are constructed on any initial supposition that they will eventually be used by other researchers, the utility of such databases and the potential yield to the often time-consuming, taxing, and frustrating effort involved are the greater if they are more widely disseminated [ [3] ]. Indeed, want of publicity is reported to be a major barrier to historians' use of electronic information resources such as databases [ [4] ]. Transferring a database to a web site is one important option for dissemination. Depending upon the imagination and ability with which such a web database is created and publicized, it may prove a boon to large numbers of researchers in a variety of fields. To current or planned historical projects involving the creation of a database, its eventual web publication is thus a possibility well worth serious consideration.

However, even irrespective of the questions of the intrinsic worth of any historical project and of the propriety of constructing a relational database from the sources or in the particular field of historical scholarship concerned, not all historical databases may be appropriate for the type of procedure described in this article. Either the form or content of the historical data itself, or any derived database, may make it difficult to display or explain to eventual searchers through a web interface. An absence of technical requirements, technical knowledge and experience, IT support, project time, or funding may prohibit the alternative here described. Finally, there are a number of technical traps lurking in the move from database to web site. Hindsight is not available to the individual scholar or project working in isolation, and the comprehensive anticipation of ensuing problems is rarely likely, even if the researcher is more fully trained in every aspect of the relevant technical tasks and problems than was the case in this project. Previous scholars' experience is thus a potential resource, the utility of which to historians contemplating the creation of a web database should not be underestimated. Although the lessons of this project are in some measure software specific, and necessarily of special application to those contemplating the construction of a Microsoft Access 2000 database and its conversion to a web site via Active Server Pages (ASP), details of the practical advantages and pitfalls of this procedure may facilitate informed planning of any future similar data-driven historical project.

.02. PROJECT BACKGROUND

The fifteen-month project "British public library annual reports, 1850-1918" funded by the British Arts and Humanities Research Board (AHRB), commenced in April 2000 and was conducted at the Department of Information and Library Studies (DILS), at the University of Wales Aberystwyth, by Dr. Chris Baggs (project manager) and Dr. G.K. Peatling (research assistant). As the nature of the project, the sources involved, and the project objectives have been described previously in this journal, these will not be explored in detail here [ [5] ]. It suffices to say that construction of a relational database of indexed data derived from the annual reports (i.e., not transcripts or images of the sources themselves), and its dissemination, preferably via a web interface, was a central project aim, although by no means the only intended outcome. Initial survey of sources, construction of the Access 2000 database, and initial data entry was undertaken during the early months of the project.

As the project commenced, it was known that the process of creating a web interface to an Access 2000 database was manageable and had a number of precedents. Specific technical aspects of this part of the project were pursued from January 2001 when the research assistant attended a course on placing databases on the WWW [ [6] ]. Reflection on the content of the course, on documentation provided for participants, and upon published guidance [ [7] ], took place alongside further data entry over subsequent months. By May 2001, the database contained complete data from a number of annual reports approaching 500.

.03. BASIC PROCEDURE

The importance of project management to historical research involving the production of a database or equivalent resource cannot be overstated [ [8] ]. Constructing the web interface to such a database, especially an Access 2000 database, is more likely to be successful if the work is divided into a number of clear stages. Firstly, initial .htm and .asp files were largely created using Microsoft FrontPage. These pages were then viewed and searched on a PC by way of a test environment. In order to test the pages as they would appear "live" without actually publishing them on the WWW, it was necessary to load Personal Web Server software onto the project PC. This was an important stage of the project; because the structure and syntax of .asp pages are extremely complex, errors frequently occurred in the initial writing of pages. Testing out the pages in an unpublished form greatly facilitated tracking down these errors and eventually saved considerable time. The writing of further pages was ongoing during this period of testing. The web interface was then actually published by loading its constituent files onto a web server appropriately configured with Microsoft's Internet Information Server software (necessary for interpreting .asp pages). The loading of files onto a web server, and the necessary testing of the public version of the web site, were conducted through the assistance and advice of the DILS IT support officer, Mr. Tim Gillison. The prior testing of the scripts themselves in a different context materially assisted any troubleshooting necessary at this stage: because the scripts had eventually successfully passed such tests, any problems that ensued clearly lay on the server side. For security reasons, using a dedicated server in such a project is an option worthy of consideration. After review of the web site, further modification of the web pages then took place: the loading of new and updated pages then fell mostly within the competence of the research team, although IT support remained vital for the project in cases of further technical difficulty. Our database web site was eventually first publicized at the ninth annual Society for the History of Authorship, Reading and Publishing (SHARP) conference in Virginia in July 2001 [ [9] ]. Further feedback was received from this forum and modifications resulted.

.04. SAMPLE ASP SCRIPT FOR A SEARCH

In principle, to execute a search via such a web interface to an Access 2000 database, in addition to the database itself, two interface files are required: one to display the initial search screen (usually containing a search form, appearing to the end user as one or many "box(es)"), and one to display search results. In some searches the first file may only require simple HTML script, although more complex script is possible. It is in processing and displaying the results that ASP script is requisite. The Appendix [see Appendix] contains an example of one of the shorter scripts underlying a results page in the web interface to the annual reports database, and may illuminate some of the principles involved.

This script can initially appear bewildering, but the good news is that many of the elements are merely necessary in order to allow the server to interpret the script; thus it is possible, as in many forms of programming, to write a large number of scripts without changing these elements much if at all. The crucial piece of script in processing searches consists in the Structured Query Language (SQL) statement:

Such SQL statements and their structure may be familiar to some readers from other contexts, particularly from queries in Microsoft Access and other database software. To those uninitiated, it may help to view the statement in three parts. First:

This specifies the database fields which one wishes to display as the results of a search. Depending on how the rest of the script is completed, for every "hit" found in the database by the end user's search term, the entry in the field called "Netfix" from the database table called "Library" can be displayed, the entry in the field "Library" from the table "Report" can be displayed, the entry in the field "ReportID" in the table "Report" can be displayed, etc. Second:

This specifies the database tables involved in the query (in this case "Library" and "Report"), and the key fields or linking fields ("Library.Library = Report.Library") that establish the one-to-many relationship between them. This is necessary in order to enable the server to process the script when a search is sent. The third element of this piece of script is:

In order to explain how this works it may help to consider the initial screen searches from which the current script is used to process [ [10]]. This search screen includes a search form containing three search fields or boxes. In the HTML script underlying this screen, these boxes have respectively been assigned the names "libtext," "datetext" and "ctytext." Consider therefore the segment of the current script reading:

This specifies that only records can be retrieved as "hits" for the user's search where the string of characters named "libtext" appears in the field "Library" in the table "Report." In other words, only records containing in the field "Library" in the table "Report" the text which the end user entered in the first box of the initial search screen can be retrieved as "hits". In plain language, one might say that the use of the common name "libtext," by linking the files underlying the search screen and the results page, should ensure that the end user gets what they are looking for. In the rest of this SQL statement, the two other names previously assigned to boxes on the initial search screen ("datetext" and "ctytext") are similarly used to effect searches of two further database fields (respectively the field "Exact dates" in the table "Report" and the field "Country" in the table "Library"). The use of the Boolean operator AND between these segments of script means that if the end user enters characters into all of these three boxes, only records will be retrieved that contain the entered character strings in all three respective fields. However, the user does not have to enter data in all three boxes; for example, a user who is effectively only interested in searching the field "Library" in the table "Report" (i.e., in this case, is only interested in searching by library) need only enter a search term in the first box on the initial search screen and the resulting "hits" will not be limited by any requirements pertaining to any other fields. Other common options in such SQL statements might feature the Boolean operators OR or NOT: OR is particularly useful if one wants to allow users to send general searches of a number of different fields.

Writing SQL statements requires precise syntax and might seem dauntingly complicated. Fortunately, this work was greatly assisted by the SQL view available in Access queries, which largely provides the required syntax. A convenient procedure is to set up or run within Microsoft Access itself a query equivalent to any which one wishes to supply over the web interface. Selecting the "SQL" option from the "View" menu within the Access query window will then display the SQL statement underlying the query. It is then possible to copy and paste this SQL statement directly into FrontPage (or whichever program one is using to write scripts). Only minor changes to this section of the script are usually required. An added advantage of this procedure is that if the query thus generated runs successfully within Access, but fails via the web interface, one may be reasonably confident that the error does not lie in this section of the script.

While the SQL statement in the sample .asp file in the Appendix [see Appendix] determines which fields in which records can be retrieved as "hits", it is a later part of the file which determines the display of "hits" in the results page. This is the section beginning:

up until:

Much of this is likely to be transparent to anyone familiar with simple HTML code. Indeed, although it is nested within segments of ASP script in this file, it mostly functions as ordinary HTML code to determine the appearance of the results page. Specifically the section beginning "<table border="1">" determines the display of search results in a tabular format. The first row of this table:

consists of a line of emboldened headers. The second row:

appears more complex, but if the hyperlink (the statement <a href …>) is ignored for the moment, in the main this amounts to a reiteration of fields specified earlier in the file for possible display as results of the search. In other words, this piece of script means that the contents of the fields "Library," "Exact dates," "No of report," "No Pages," etc., for a "hit" can be enunciated in a second row of this table. However, crucially, this piece of code is nested within two lines of ASP script: <% Do while Not RSlist.Eof %> and <% RSlist.Movenext Loop %>. These set the process of displaying the contents of the specified fields to repeat for each record in the database which fulfills the parameters of the entered search, until no more such records are found. Thus entries in the fields listed in this section of code will be displayed for all "hits," or all records that the end user has effectively requested.

A practical test with the relevant section of the web database may help further to illuminate the above explanation. This relevant section enables the end user to search for annual reports indexed in the database, and display summary details thereof. One must undertake such a test from the relevant page [ [11]], entering or selecting appropriate text in any or all box(es) in the search form. For instance, enter "1875" (without the quotes) in the second box for date. Then click the button "Send Search." The subsequent page displays summary details of annual reports, and is that created by the script appearing in the Appendix [see Appendix]; the relationship between at least sections of the script and the appearance of this page should be clear.

.05. MAXIMIZING UTILITY

With appropriate hardware and software requirements in place, the resources of the AHRB and UWA, and the consummate technical knowledge, backup and skill of Tim Gillison, the bare creation of a web interface to the database was not a particularly exacting task for members of the project team. Maximizing its potential utility to researchers was a far more testing conceptual and practical task. What made this an especially important and difficult part of the project was the decision taken earlier to describe and index, so far as was possible, every item of content in the surveyed annual reports. The resulting great variety of data in the database implied a correspondingly large range of possible uses: the database is a potential resource for local, social, cultural, museum, and library historians to name but a few. This in turn meant that it was desirable to create in the interface a variety of search functionalities and routes into the database, and to make these as accessible as possible. Three aspects of this work were particularly important:

1. Making available large numbers of possible searches and numbers of fields that could be searched. In this project we implemented a procedure of categorizing data contained in the public library annual reports into broad data types [ [12]]. This necessitated a structurally complex Access database, containing 59 tables. A large number of searches were possible within Access itself, and it was the intention to replicate these possibilities on the web site wherever most likely to be of use. In practice, this meant creating a number of search options for each broad data type and the ability to search by library, by year and for individual people, as well as options for combining these searches. Because in some cases a separate file had to be created for each page used to display a search option and for each page used to display the corresponding results, the number of files underlying the interface rapidly mushroomed; there were over 300 interface files at the conclusion of project. The full range of search options available are listed on the "Select Search" screen [ [13]].
2. Help or explanation on the interface as to how to navigate the web site. There is little use in disseminating a database via a web site unless the end user can understand how to use it. Ultimately, each visitor to the web site will have her/his own experience and views as to how helpful is the design, perhaps influenced by the prominence or otherwise of the search(es) most relevant to her/his research interests. We do not imagine that the site will satisfy every visitor. Nonetheless, a few basic principles have been adhered to as far as possible, which we hope will make the time visitors spend on the site more efficient:
   • Reducing the necessity of scrolling on pages. Few users of the WWW have the patience to scroll on a page. While dedicated researchers are likely to have more patience than the superficial surfer, the web site has been designed so far as possible, at least on initial search pages, to keep the necessity of scrolling down to a minimum. Much of the information on such pages can usually be accessed by selecting a link or links near the top of each view. In screens which may display a large number of search results, it is harder to obviate the need for scrolling; arguably, on sending a search the user is likely to desire the most comprehensive immediate view of her/his "hits".
   • Repeating explanatory text. Once again, as the attention span of web surfers tends to be short, crucial text guiding users' searches or explaining their results is repeated several times in the interface so that they will be less likely to miss it.
   • "See also" references. When a user selects a particular type of search, opportunity is taken to alert them to tangential search options available within the database.
   • Examples and pop-up hints. On many search screens, help and hints are provided as to how a particular search option may best be used. In some cases, these appear in the form of a second window that the user can close when s/he desires, and sometimes employ rudimentary JavaScript.
   Creating a decorative web site has not been treated as an urgent task to date, so that the interface makes substantial use of default colors and fonts. If comments are received about this it is not a desperately difficult aspect to enhance subsequently through Microsoft FrontPage.
3. Hyperlinking within the database. Hyperlinking on an ordinary web site rapidly expands the number of possible routes of navigation thus empowering the user with possibilities of choice and selection; to adapt fashionable academic discourse, each visitor to a web site can create her/his own narrative [ [14]]. This can be especially true of a web interface to a database. The multivocality of such a web site rapidly expands the possible combinations of sequences of searches, results, and thus uses.

Considering the following section of script discussed earlier, used for searching for and displaying summary details of annual reports in the database, can help to illustrate this point [ [15]]:

Those familiar with simple HTML code will recognize the form <a href= "…">…</a> as the basic structure of code that creates a hyperlink in a web page. It may also be clear that <a href="place.asp…">…</a> points to another file on the same server. The remainder of this code consists mainly of nested ASP script and partly of a trick that involves an adaptation of the way in which a server processes such script. This processing has the effect of adding text in the form "?x=y" to the URL to create a new URL usually specific to each individual search, where "x" is the name given by the web-site designer elsewhere to the search term entered by the user, and "y" is that search term. Knowing that the label "x" in this case is "liby," we used this feature to create hyperlinks that the server can effectively treat as new searches. The name of the virtual "file" retrieved when this hyperlink is selected is completed by <%=RSlist("Netfix")%> (or the "y" element mentioned above, usually a search term). "Netfix" is one of the fields that we previously specified could be retrieved for each record located as a "hit" in the initial search. This means that in the results page, each "hit" contains a hyperlink that effectively can act as a new search of a different section of the database. In each case, the text of the hyperlink so formed is established by the section of script <%=RSlist("Library")%>, another field (corresponding to the name or location of the relevant library) that we previously specified could be retrieved for each report located as a "hit" in the initial search.

The practical effect of this section of script containing the hyperlink may again be clearer if one attempts another search from the "Search for reports issued by particular libraries or falling in particular years" page [ [16]]. In the subsequent page of results, the effect of the script should be evident in the column headed "Library." No matter how many "hits" one's initial search retrieves, each entry in this column should appear as a hyperlink. Following such a hyperlink (a process known as "drilling down") displays a few details about the location selected.

In fact, this is a fairly unambitious example of this functionality because it merely displays a little extra data about the selected item. More ambitious examples may be found within the database, for instance by going to the "Search visitors information types" page [ [16]], and clicking on the button "Display all index items". This displays all the categories (and attached notes) used to index the different types of statistical information pertaining to visitors contained within public library annual reports. Each entry in the column "Category of Visitors information" again appears as a hyperlink; but in this case, "drilling down" through the hyperlink will display a screen from which a further search may be attempted, limited to the selected category of visitors information (and a particular library if one desires). The results of such a search will display details of specific references in annual reports to information pertaining to visitors to libraries and allied cultural institutions, limited by these parameters.

.06. PROBLEMS AND LIMITATIONS

While the procedures and technical solutions described above have been successfully applied in this project insofar as a web site has been successfully created, it would be inaccurate to represent them as a requisite for a huge number of current or future research projects. It is important thus to highlight the factors that ought to mitigate any naïve enthusiasm for web databases (especially where based on Microsoft Access 2000 and ASP) in historical research, and to suggest some of the circumstances in which such a strategy ought not to be applied to historical research projects.

Time commitment

The procedures described in this article merely for the writing, testing and implementation of .asp and .htm scripts required one researcher around two months' intensive and dedicated work at a minimal estimate. Time was not a luxury on this project; person-hours not applied to creating the web interface could have been applied in expanding the remit of the Access database itself or in producing or enhancing other outcomes from the project. Depending on the nature of each research project, the potential for other forms of publication, the nature of the sources and the ease with which they may be recorded or represented in a relational database, and the size of the likely scholarly user base for a web database, the construction of a web database as here described may be thought a relatively unproductive enterprise. This is especially the case where academics face substantial other commitments to research, publish and teach. Ideally, a long-term commitment of dedicated staff time to a project involving the construction of a web database should also be allowed. Significant refinements and expansions to a web interface are likely to accrue, as well as active responses to feedback from users. Unfortunately, academic career structures and even academic politics may inhibit these possibilities. Computerization certainly has a multiplicity of significances for the way academics work, including its effect on power structures within universities [ [18]]. In certain quarters, one response to this perceived threat might be to begrudge commitments of time and money to projects with a high technical content. Indeed, partly because academic expectations of such resources are framed by experience of commercially supplied databases and database systems (which are often the fruit of enormous hidden investments in resources), and partly because a want of understanding exists between certain branches of academia and local IT support officers (at least in some universities), academics may respond over-critically to the outcomes of such projects. We were fortunate, through the support of the AHRB and UWA, to be protected from many such difficulties. But where these problems are intensely experienced, a practical (if perhaps short-term) solution may be not to pursue procedures such as those described in this article.

Training

As far as the aspect of the project here described achieved positive results, these would not have been possible without the willingness of the researchers' department and funding body to release resources for necessary training, and without some pre-existing training and knowledge on the part of the researchers. Specialized courses and literature in this field are expensive; even university departments and units that now provide such resources often aim to make such operations commercially viable if not lucrative. Where training resources cannot be obtained, any research project similar to ours will face substantial disadvantages.

Technical Support

The technical support and resources provided at UWA were critical preconditions to this project. However, in view of the demands typically made on IT support officers in universities, even the best technical support is unlikely to be a complete substitute for knowledge, experience, or training in the research team. A fruitful division of technical labor should be established, and again, the positive benefits from good relations between academic departments and local IT support cannot be overemphasized.

Software Specific Issues

The combination of Microsoft Access and ASP generally served this project well. However, commitment to specific software, which is a necessary stage of any technically orientated historical project, may involve pitfalls and possible sources of regret or doubt when it is too late to turn back. Relational database software was necessary to this project, and the choice of Microsoft Access within this subset was made significantly more attractive (though not determined) by researchers' previous experience. We were generally accurate (or fortunate) in our choice, and found the software pliant to our needs. In connection with the "hyperlinking" features of the web interface discussed above, however, the way we had used the software came back to haunt us at least once. Only late in the project did we realize that it would be advantageous to use hyperlinks in certain cases textual entries in the database in which spaces were practically unavoidable. This would have created search-specific URLs containing spaces. While Microsoft's Internet Explorer can cope with such URLs, Netscape browsers often have difficulties with "parsing" in such circumstances. As we did not wish to disadvantage Netscape users searching the database, this issue was patched up by belatedly adding a couple of extra fields to the underlying Access database. Making retrospective changes to the structure of a database can be a perilous enterprise, so such changes were kept to a minimum. This issue appears to highlight a hidden advantage of using an autonumber ID field in each table when creating a Microsoft Access database, which it may be advisable to bear in mind when initially designing one's database. More generally, it is as well to be aware that software selection in a project such as ours is always a more significant choice than it seems at the time; the more complex the outcomes, the more stages of evolution through which the database passes, the more traps await.

Transition From Database to Web Site

In general, we were reasonably successful in replicating the search functionality present in the database within Microsoft Access on the web interface. Nevertheless, in a couple of cases, functionality was lost or was difficult to provide in the web interface.

On running a query within Access, sorting results according to the alphabetical or numerical content of any field is usually simple. The underlying SQL command, the ORDER BY function, is straightforward. However, within the time limitations of this project, it has not proved possible to resolve the issue of giving the end user themselves the option via the web interface of sorting results according to the field of their preference. This is clearly not an irresoluble issue because a number of databases available via the WWW provide similar functions; they are often found, for instance, in automated library catalogues. There was not enough time for the experimentation that would have been necessary to confirm a preferred solution. The result may be found frustrating to the end user with a large number of "hits" not listed as they might wish by alphabetical order of library (for instance).

Collating Results From Very Different Sections of the Database

One technically difficult aim in constructing the web site was to provide single searches collating information as "hits" that come from records in very different parts of the database. A theoretical example might help to explain the difficulty. One might conceptualize a search that will retrieve as hits records containing element x in field y, or element a in field b (or any combination of these). If record z contains element x in field y and record c contains element a in field b, if records z and c have tables p, q, and r in common, it is certainly possible to display certain fields of records z and c from the tables p, q, and r on a search results page. It is not only possible but also desirable to do so, because such fields are likely to contain data that contextualizes and thus makes meaningful manifestations of elements x and a. Technical and conceptual difficulties arise where records z and c do not have tables p, q, and r in common. Where, owing to database design issues, decisions had been taken to record data in different parts of the relational Access database, even if they pertained to similar or identical aspects of public library practice, this sometimes became an obstacle to displaying such data together as search results. The sources of the difficulty were:

1. Formulating search syntax that would search in (say) table p in the case of record z but not in the case of record c, where record c has no connection with table p. In such a case, if the search included a request to look for table p in connection with record c, the server would probably be unable to process the request. Yet it would still be desirable to look for and retrieve data from table p in the case of record z, and perhaps table q in the case of record c, in order to provide the user with crucial explanatory information about such records.
2. Describing and displaying such search functionality and results in a way that would be meaningful to the end user and enable them to maximize the potential of the database. Ideally, a user should be troubled neither with the facts that the data they require is stored in different parts of the database, nor that different fields have to be searched to obtain the data in which they are interested.

One solution is to render invisible to the user the fact that their search term is being sent in series to multiple fields in different parts of the database. Such a procedure is in use in the database, and can be seen at the page "Search for reports issued by particular libraries or falling in particular years" [ [19]]. Enter or select a place, year, or country in the appropriate box (for instance select "Wales" from the drop-down list for country), and click on the button "send Search." From the next screen, choose any report by clicking any radio button [ [20]] in the "Select report" column, and then click the "Show further details of the selected report" button at the bottom of the screen. The subsequent screen provides an option to "Display details of your selected report." Clicking this button in fact activates a search of twenty-seven different fields in twenty-seven different parts of the database. While the user has only been required to select a report once, and sees the results (after a short delay) as if displayed from a single search, the final operation in this sequence sends twenty-seven different searches, each to a different field in a different database table [ [21]].

A modified version of this operation may have provided solutions to other issues in the construction of the web interface, but it did not prove possible, within the time constraints of the project, to experiment fully and to implement such a solution. It is not exactly clear that this problem would have been easier to resolve if the underlying Access database had been designed in a different way, at least without depriving the end user of some other useful resources or possibilities within the database. It is also possible that there is a simpler solution to such a problem, but again, we could not ascertain this within the time limit on the project. The important (if deceptively platitudinous) lesson that arises is that it is practically impossible to have too much time for work such as the creation of a web interface to an Access database.

Further Publicity

Given the effort involved in this stage of such a project, creating a web interface to a database may seem an achievement in itself. Unfortunately, this is unlikely to be sufficient, given the vast and increasing number of web pages through which the scholarly user would have to wade in order to find such a resource. A few additional steps are desirable:

• Submission of the site to search engines.
• Inclusion of metadata within the site, or at least with the front page.
• Most importantly, publicity should be targeted at the scholarly communities most likely to find the research materials concerned of interest. Appropriate methods of publicity include academic newsletters, e-mail lists and conferences, as well as ordinary processes of networking. Any published articles citing the database as a source are likely to have a cumulative effect.

In an ideal case again, time should be available to tasks so integral to a project such as that here described.

.07. CONCLUSION

WWW dissemination of historical databases is an important strategy that has much to offer scholarship. Our experience shows that it is a feasible option even for researchers whose initial expertise lies largely in other areas. However, certain preconditions should be in place before any similar such project is attempted: in particular, sufficient time, prior knowledge and/or training resources, and IT support should be available. Even if these conditions can be attained, technical limitations on what can be done will remain and may foreclose the creation of a web interface to a historical database as a sensible strategy.

Ultimately, researchers on every project have a large number of possible methods and technical solutions to weigh up, and it is unlikely that the specific procedures we implemented will be appropriate to more than a small fraction. Narratives of experience from the perspectives of historians and researchers may be particularly likely to promote informed methodological decisions. Indeed, we hope that this article will be of material assistance to researchers who are conducting or will conduct projects using similar methods and software to those we employed. However, if the only consequence of this article is to discourage researchers from applying such methods to projects to which the methods are not particularly well suited, this itself will be the kind of service to scholarship that we have learned not to underestimate.

.08. NOTES

1. G.K. Peatling and Chris Baggs, ‘Creating a Database of British Public Library Annual Reports, 1850-1919', Journal of the Association for History and Computing, iii, nr. 3, (Nov. 2000), available at http://hdl.handle.net/2027/spo.3310410.0003.302.

2. See ‘Public Library Annual Reports 1850-1919: A Searchable Database', available at http://www.dils.aber.ac.uk/dils/an_rep/.

3. See ‘4.1 Introduction' http://hds.essex.ac.uk/g2gp/digitising_history/sect41.asp, in ‘Chapter 4: Further Data and Preservation Issues', in Sean Townsend, Cressida Chappell and Oscar Struijvé, Digitising History: A Guide to Creating Digital Resources from Historical Documents , AHDS Guides to Good Practice (Arts and Humanities Data Service, 1999), available at http://hds.essex.ac.uk/g2gp/digitising_history/.

4. Deborah Lines Andersen, ‘Academic Historians, Electronic Information Access Technologies, and the World Wide Web: A Longitudinal Study of Factors Affecting Use and Barriers to That Use', Journal of the Association for History and Computing, i, nr. 1, (June 1998), available at http://hdl.handle.net/2027/spo.3310410.0001.101.

5. Peatling and Baggs, ‘Creating a Database of British Public Library Annual Reports, 1850-1919' , available at http://hdl.handle.net/2027/spo.3310410.0003.302.

6. The course in question was run through the Humanities Computing Unit at Oxford University, and was called ‘Putting your database on the Web'. Details are available at http://www.hcu.ox.ac.uk/winter/databases.html, available via the Humanities Computing Unit (HCU) web site at http://www.hcu.ox.ac.uk/.

7. In order of helpfulness, these included John Kauffman, Beginning ASP Databases (Birmingham: Wrox Press, 1999): Scott Mitchell and James Atkinson, SAMS Teach Yourself Active Server Pages 3.0 in 21 Days (Indianapolis: SAMS, 2000), 216-52, 267-71, 485-530, 593-622: Richard Anderson et alia, ASP 3.0 Programmer's Reference (Birmingham: Wrox Press, 2000): Jesse Feiler, Database-driven Web Sites (Boston: AP Professional, 1999), 114-7, 127-35, 207-17.

8. Charles Harvey and Jon Press, Databases in Historical Research: Theory, Methods and Applications (Basingstoke: Macmillan, 1996), 74-97.

9. SHARP 2001 9^th annual conference web site, located at http://www.wm.edu/CAS/ASP/SHARP/, available via the SHARP web site at http://www.sharpweb.org/.

10. The screen entitled ‘Search for reports issued by particular libraries or falling in particular years', available at http://www.dils.aber.ac.uk/dils/an_rep/library.htm.

11. ‘Search for reports issued by particular libraries or falling in particular years', available at http://www.dils.aber.ac.uk/dils/an_rep/library.htm.

12. See Peatling and Baggs, ‘Creating a Database of British Public Library Annual Reports, 1850-1919', especially http://mcel.pacificu.edu/JAHC/JAHCIII3/ARTICLES/peatling/#Anchor-46919.

13. See http://www.dils.aber.ac.uk/dils/an_rep/begin.htm.

14. Paul Delany and George P. Landow, ‘Managing the Digital Word: The Text in an Age of Electronic Reproduction' in George P. Landow and Paul Delany eds., The Digital Word: Text-based Computing in the Humanities (Cambridge, Mass.: MIT Press, 1993), 1-28, especially, 10-5: George P. Landow, Hypertext: The Convergence of Contemporary Critical Theory and Technology (Baltimore: Johns Hopkins University Press, 1992), especially 2-7, 57-70, 109-12, 203.

15. These searches may be sent from the page ‘Search for reports issued by particular libraries or falling in particular years', available at http://www.dils.aber.ac.uk/dils/an_rep/library.htm.

16. I.e., go to http://www.dils.aber.ac.uk/dils/an_rep/library.htm and enter an appropriate search term in any or all box(es) in the search form (for instance, enter "Aberdeen" (without the quotes) in the first box) and click on the "Send Search" button.

17. Available at http://www.dils.aber.ac.uk/dils/an_rep/vistype.htm.

18. See for instance the discussion in Stanley N. Katz, ‘Making Information Technology Serve Higher Education, Rather Than the Other Way Around' , Journal of the Association for History and Computing, iv, nr. 2, (Aug. 2001), available at http://hdl.handle.net/2027/spo.3310410.0004.204.

19. Available at http://www.dils.aber.ac.uk/dils/an_rep/library.htm.

20. A radio button is a feature which sometimes appears in HTML forms. It functions like a checkbox in that clicking on a particular button selects the item in a list to which it is linked. The most important difference between a radio button and a checkbox is that only a single item in a list attached to radio buttons may be selected at any one time, whereas multiple items in a list attached to checkboxes may be selected or checked.

21. If you have difficulty following these guidelines, the effect can be simulated rapidly by entering (or clicking) the following URL: http://www.dils.aber.ac.uk/dils/an_rep/repsearch.asp?Sel=4&sid=4&did=4&bid=4&tid=4&vid=4&qid=4&oid=4&hid=4&wid=4&nid=4&gid=4&fid=4&kid=4&iid=4&jid=4&zid=4&pid=4&rid=4&meid=4&xid=4&uid=4&yid=4&eid=4&cid=4&lid=4&aid=4 The length of the URL is a clue to the fact that multiple searches are in fact being undertaken, as well as to the complexity of the operation.

Bibliography

Andersen, Deborah Lines. ‘Academic Historians, Electronic Information Access Technologies, and the World Wide Web: A Longitudinal Study of Factors Affecting Use and Barriers to That Use', Journal of the Association for History and Computing, i, nr. 1, (June 1998), available at http://hdl.handle.net/2027/spo.3310410.0001.101.

Anderson, Richard, et alia. ASP 3.0 Programmer's Reference (Birmingham: Wrox Press, 2000).

Delany, Paul and George P. Landow. ‘Managing the Digital Word: The Text in an Age of Electronic Reproduction', in: George P. Landow and Paul Delany, eds. The Digital word: text-based computing in the humanities (Cambridge, Mass.: MIT Press, 1993), 1-28.

Feiler, Jesse. Database-driven Web Sites (Boston: AP Professional, 1999).

Harvey, Charles and Jon Press. Databases in Historical Research: Theory, Methods and Applications (Basingstoke: Macmillan, 1996).

Humanities Computing Unit, Oxford University, ‘Putting your database on the Web', available at http://www.hcu.ox.ac.uk/winter/databases.html, available via the Humanities Computing Unit (HCU) web site at http://www.hcu.ox.ac.uk/.

Katz, Stanley N. ‘Making Information Technology Serve Higher Education, Rather Than the Other Way Around' , Journal of the Association for History and Computing, iv, nr. 2, (Aug. 2001), available at http://hdl.handle.net/2027/spo.3310410.0004.204.

Kauffman, John. Beginning ASP Databases (Birmingham: Wrox Press, 1999).

Landow, George P. Hypertext: The Convergence of Contemporary Critical Theory and Technology (Baltimore: Johns Hopkins University Press, 1992).

Mitchell, Scott and James Atkinson. SAMS Teach Yourself Active Server Pages 3.0 in 21 Days (Indianapolis: SAMS, 2000).

Peatling, G.K., and Chris Baggs. ‘Creating a Database of British Public Library Annual Reports, 1850-1919', Journal of the Association for History and Computing, iii, nr. 3, (Nov. 2000), available at http://hdl.handle.net/2027/spo.3310410.0003.302.

‘Public Library Annual Reports 1850-1919: A Searchable Database', available at http://www.dils.aber.ac.uk/dils/an_rep/.

SHARP 2001 9^th annual conference web site, available at http://www.wm.edu/CAS/ASP/SHARP/, available via the SHARP (Society for the History of Authorship Reading and Publishing) web site at http://www.sharpweb.org/.

Townsend, Sean, Cressida Chappell and Oscar Struijvé. Digitising History: A Guide to Creating Digital Resources from Historical Documents, AHDS Guides to Good Practice (Arts and Humanities Data Service, 1999), available at http://hds.essex.ac.uk/g2gp/digitising_history/index.html.

10. Appendix

<%

'Declare variables and open connection

Set DataConn = Server.CreateObject("ADODB.Connection")

DataConn.Open "Libreports"

set RSlist = createobject("adodb.recordset")

dim myquery

libtext = Request("libtext")

datetext = Request("datetext")

ctytext = Request("ctytext")

myquery = "SELECT Library.Netfix, Report.Library, Report.ReportID, Report.[Exact dates], Report.[No of report], Report.[No Pages], Report.Signatories, Report.[Institutions declared covered] FROM Library INNER JOIN Report ON Library.Library = Report.Library WHERE (((Report.Library) LIKE '%" & libtext & "%') AND ((Report.[Exact dates]) LIKE '%" & datetext & "%') AND ((Library.Country) LIKE '%" & ctytext & "%'))"

RSlist.open myquery,DataConn,1,1

%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML>

<HEAD>

<title>Results of your search</title>

</HEAD>

<BODY>

<H2>Results of your search</H2>

<p>Your search for "<%=libtext%>&nbsp;<%=datetext%>&nbsp;<%=ctytext%>" returned <em><%=RSlist.RecordCount%></em> records.</p>

<p>To see further details of any particular report, select a report in the "Select report" column, then click the button "Show further details of the selected report" at the bottom of the page.</p>

<p>Alternatively you may display details of a particular location by clicking on the location in the "Library" column.</p>

<form action="select.asp">

<table border="1">

<tr><td><b>Library</b></td><td><b>Dates</b></td><td><b>Issue no.</b></td><td><b>No. of pages</b></td><td><b><a href=Signatories.asp>Signatories</a></b></td><td><b>Institutions declared covered</b></td><td><b>Select report</b></td></tr>

<% Do while Not RSlist.Eof %>

<tr><td><a href="place.asp?liby=<%=RSlist("Netfix")%>"><%=RSlist("Library")%></a></td><td><%=RSlist("Exact dates")%></td><td><%=RSlist("No of report")%></td><td><%=RSlist("No Pages")%></td><td><%=RSlist("Signatories")%></td><td><%=RSlist("Institutions declared covered")%></td><td><INPUT TYPE="radio" NAME="Sel" VALUE="<%=RSlist("ReportID")%>" </td></tr>

<% RSlist.Movenext

Loop %>

</table>

<p><input type="submit" value="Show further details of the selected report"> </p>

</form>

</BODY>

</HTML>

<%

' Close database conection

RSlist.Close

DataConn.Close

' Free up memory

Set RSlist = Nothing

Set DataConn = Nothing

%>