ORDS How-To 07: Query data

1. About this guide

This document is one of a series of How-To guides for the Online Research Database Service (ORDS). It will tell you how to query databases within the ORDS system.

Contents

1.1. Pre-requisites

This How-To assumes that you have already registered to use the ORDS, and have either created or been given access to at least one project containing at least one database.

If this is not the case, please see the earlier guides in this series. These can be accessed via the main ORDS documentation page.

2. The View, Edit, and Query Data page

All ORDS project members can query the data in ORDS databases. To do this, you will need to go to the View, Edit, and Query Data page for the database version you wish to work with.

To reach this, log in to the ORDS via https://app.ords.ox.ac.uk, You will see a list of your ORDS projects. Click the name of the project which contains the relevant database.

You will be taken to the project page, where you will see a list of all the databases that project contains. Click the database name to go to the database page.

ORDS allows you to have up to three versions of each database. All databases will have a main version; it is also possible to create milestone and test versions. (For further information on creating and working with database versions, see the earlier guide in this series, How to manage databases and database versions.)

Towards the bottom of the database page, you will see three panes – one for each of the three possible versions. The options available in each pane will vary depending on which versions you currently have.

Data in any database version can be queried. Click the View, edit, and query data button in the information pane for the desired version.

(The database shown above has only a main version; if there were test or milestone versions, a View, edit, and query data button would also be visible in the other panes.)

You will be taken to the View, Edit, and Query Data page. On the left-hand side of the page, you will see a list of the tables in the database. On the right-hand side are a number of buttons. Two of these buttons – Query data using query builder and Query data using SQL – will take you to ORDS query tools.

View, Edit, and Query Data page, with query tool buttons highlighted

The query builder is a graphical interface which allows you to construct simple queries by selecting tables and fields from within them. It is straightforward to use, but its scope is limited. This is covered in section 3. below.

The SQL query page is more powerful, but requires knowledge of SQL (Structured Query Language). This is covered in section 4. below.

3. Querying data using the query builder

The query builder allows you to select one or more tables from your database, and view the contents of some or all of the fields. It does not yet support conditional queries (that is, queries which return only the records which meet a specified set of criteria), or other more complex queries, though we hope to be able to expand its functionality in the future. If you wish to run queries that aren't possible using the query builder alone, see section 3.2. below for advice on how to use the query builder as a starting point for creating more complex queries, or section 4. below for details of the SQL query page.

To open the query builder, click Query data using query builder on the View, Edit, and Query Data page.

Query builder

The query builder has three main components:

The working area occupies the top left-hand part of the screen. The database tables will appear here. If you need more space, you can increase the size of the working area by dragging its lower right-hand corner

The table list normally appears in the top right-hand part of the screen (in narrow windows, it may move to below the working area). You will see a list of all the tables in the database.

The query box appears towards the bottom of the screen. As you select fields to be included in the query, you will see an SQL statement appear here.

To include a table in the query, click the check box that appears next to the table's name in the table list. To remove a table from the query, click the check box again to uncheck it.

Let's begin with a simple query which only uses a single table - tblarticles. Once we have checked the tblarticles box in the table list, the table appears in the working area.

Query builder with one table selected

The table contains a list of all its fields, each with its own check box. We'll check all of them, to include the whole contents of the table in this query.

Query builder, showing one table with all fields selected

The query builder has generated an SQL statement reflecting the selection of fields. This can be seen in the query box. We can now click Run query to see the results.

The query results will appear in a new tab.

Query results

All the fields are present, but notice that the journal and author fields only contain numbers. This is because these are both linked fields, which draw on information from other tables. The journal and author fields are displaying the contents of the primary key field of the linked-to records, which contains only a number (like tblarticles's own id field, which can also be seen in the table above), and hence isn't very informative. Fortunately, we can use the query builder to construct a query that will give us the contents of other fields from the linked-to tables.

Let's return to the query builder and select some additional tables.

Query builder with three tables selected

The relationships between the tables are represented by curved lines. (tblarticles is now on the right. Tables can be dragged around the working area as desired - it is often helpful to do this to arrange the tables so the relationships can be seen clearly.) We can see from the diagram that the journal field in tblarticles links to tbljournals, and the author field to tblauthors.

We now need to select the additional fields we'd like to appear in our query. We'll select the journal_name and publisher fields from tbljournals, and the author_name field from tblauthors. (We could also select any of the others that we'd like to include.) Additionally, we'll deselect the journal and author fields from tblarticles, as we already know that these only contain an uninformative primary key.

Query builder, showing a three-table query

The SQL statement in the query box has updated to reflect this new, more complex query. We can now click Run query again, to refresh the contents of the results tab.

Results of revised query

These results are rather more informative!

We can sort the results by one of the fields by clicking on the field name - a small arrow will appear next to it. Clicking the same field name a second time reverses the direction of the sort (and also inverts the arrow). Let's sort the results by the author_name field.

Results of complex query, sorted by author name

For further details of what can be done with query results, see section 5. below.

3.1. Solutions to a common problem - unjoined tables

Suppose that we wanted to see a list of all the authors in this database, with all the journals they've been published in. We might expect that the way to do this would be to simply select the author field from tblauthors, and the journal field from tbljournals.

However, if we do this, ORDS displays a warning message. This happens because the two tables we've selected aren't directly connected by any relationships.

Query builder showing unjoined tables

If we ignore the warning and run the query, the results may be rather unexpected.

Query results for query on unjoined tables

There are eighty results in the list. As the query we ran in the previous section indicated that there are records for just fifteen articles in this database, this seems an implausible result.

If we look more closely at the results table, we'll see that in fact it contains an entry for every author in tblauthors with every journal in tbljournals - regardless of whether the database indicates that the author has been published in that journal. There are ten authors and eight journals - hence eighty entries in the results table. This is clearly not what we were looking for!

This happens because of a quirk in the way SQL works: if no explicit indication of the link between two tables is included in the SQL statement, the result will be what is known as the Cartesian product of the records in these tables - a list of all possible combinations of the records in the tables.

We therefore need to find a way of indicating what the link is. Although the two tables we've selected are not connected by a direct relationship, they are connected indirectly: tblauthors and tbljournals are both linked to by tblarticles. tblarticles is, in fact, a key information source for this query: it's there that the connections between specific authors and specific journals are actually listed, in the form of records for published articles. We therefore need to include this in the query.

If we select tblarticles in the query builder, three things happen. First, all tables in the diagram are now linked by the curved lines that indicate relationships. Secondly (as a result of this), the warning disappears. Thirdly, the SQL statement in the query box expands to include a WHERE clause.

Query builder showing three tables, now joined

Note that it's not necessary to select any fields from tblarticles: simply having it displayed in the diagram is enough to tell the query builder that we would like to see a list of authors and journals as linked by the information listed in tblarticles.

If we now run the query, we get a much more plausible fifteen results. (There are some duplicate records in the list, but this is not a mistake: it simply indicates that the same author has published in the same journal multiple times.)

Results of new query with all tables joined

As a general rule of thumb, the problem described above can be avoided by ensuring that all tables shown in the query builder are linked to at least one other table by a visible relationship. In some cases, however, the database structure may be such that this is not possible - the relationships between tables may simply not exist. If this happens, there are two possible ways forward. First, the database structure can be revisited, and additional relationships added. This can be done via the schema designer - see How to build and structure databases for more information. Secondly, a WHERE clause can be manually added to the SQL statement to indicate the nature of the link. If you require help doing either of these, please contact the ORDS help desk by emailing ords@it.ox.ac.uk.

3.2. Creating more complex queries

Although the query builder is currently somewhat limited in scope, it is possible to use it as a starting point for creating more complex queries.

The SQL statement generated by the query builder can be edited manually. For example, it is possible to change the order in which fields appear in the query results by editing the order in which the table and field names appear in the statement (ensuring that the punctuation around these remains intact). Those with further knowledge of SQL can also add additional clauses - e.g. WHERE or ORDER BY - to the statement before running the query.

Another option is to copy and paste the SQL statement from the query builder into the SQL query page, and continue to edit it there. The SQL query page provides a little more structure, and some links to help resources - see section 4. below for more details.

If you need assistance with querying your database, the ORDS team may be able to help: please contact the help desk by emailing ords@it.ox.ac.uk.

4. Querying data using the SQL query page

4.1. About the SQL query page and SQL

The SQL query page is a flexible tool which can be used to construct complex queries. These include queries which contain conditional statements, where the results are ordered according to specified criteria, or where simple mathematical operations are applied to data.

However, it requires knowledge of SQL (Structured Query Language) – a formal language used to query databases. Although SQL may initially look slightly cryptic, it is possible to gain a reasonable grasp of the main principles relatively quickly. A basic guide to some key commands is offered in section 4.3. below, and plenty of books and online guides to the language are available. In particular, W3schools.com offers a helpful SQL tutorial.

If you need assistance with querying your database, the ORDS team may be able to help: please contact the help desk by emailing ords@it.ox.ac.uk. For example, it may be possible to provide you with some sample queries that you can use as a template, or to help set up dynamic datasets (saved queries) for queries you wish to be able to rerun.

SQL is a very powerful language: in other contexts, it is also used to edit or delete data and database tables. However, in the ORDS query tools, it is used only for interrogating existing data: safeguards are built in to prevent accidental loss or overwriting. (If you enter an SQL statement designed to edit or delete data, the ORDS will not permit it to run, and instead you'll see an error message.)

4.2. Using the SQL query page

To open the SQL query page, click Query data using SQL on the View, Edit, and Query Data page.

ORDS SQL query page

The page provides separate fields for each clause of an SQL query, with some help text (and links to further information) on the right-hand side. Each field can be resized by dragging its lower right-hand corner.

When typing in an SQL query, there is no need to enter the SQL command that appears immediately before the field (e.g. SELECT, FROM, etc.): ORDS will supply this automatically. If you do enter one of these commands, ORDS will delete it.

If ORDS detects that you have entered a command which belongs in another field, it will attempt to move you there. (This means that you can start typing an SQL query in the SELECT field, and, by including the SQL commands, prompt ORDS to move you through the fields as required. This may be a more efficient way of working for those who are already familiar with SQL.)

If you have a pre-written SQL query, you can paste this into the SELECT field, and ORDS will separate it into its component parts.

Many systems that use SQL require a semi-colon to be entered at the end of each statement. This is not needed in the ORDS SQL query page.

By convention, SQL commands (such as SELECT and JOIN) are written using upper case letters. That convention is followed in the examples given below. However, where such commands need to be entered into the fields of the SQL query page, this can in fact be done using either upper or lower case.

Once you have entered your query, click Run query. Your query results will be displayed in a new browser tab. Results can be sorted by clicking on the column headers. Clicking the same column header a second time reverses the direction of the sort.

To run another query, click Clear query to clear the query page and start again.

For further details of what can be done with query results, see section 5. below.

4.3. SQL basics

There are many books and websites which provide comprehensive guides to SQL - see, for example, the W3Schools SQL Tutorial. This section is simply intended to provide some basic pointers regarding some commonly used commands.

The ORDS SQL query page provides seven fields for the clauses of an SQL query. Brief notes are given about each below.

Only the SELECT and FROM fields are mandatory - the others are used for specific types of query. Some of the fields can contain additional commands - a few examples are given in section 4.3.8. below.

The examples below make use of the same bibliography database used in the sample queries in section 3. above. This database consists of three tables (tblauthors, tblarticles, and tbljournals), each with a number of fields.

Bibliography database structure

4.3.1. SELECT

This is used to specify the field(s) to be included in the query. Field names should be separated by commas. An asterisk (*) can be used to represent all the fields in a given table.

If a field name contains spaces or upper case letters, it should be enclosed in double quotation marks (e.g. "field name").

4.3.2. FROM

This is used to specify the table(s) from which the fields are taken. Table names should be separated by commas. If a table name contains spaces or upper case letters, it should be enclosed in double quotation marks (e.g. "table name").

A simple query using just the SELECT and FROM fields might look like this:

SELECT
author, title, year

FROM
tblarticles

This would return the contents of the three listed fields from tblarticles.

Results of simple SELECT query

Notice, however, that the author field contains only a number. This is because it's a linked field, which draws on information from another table (in this case tblauthors - we can see this by looking at the database structure diagram above). The author field is displaying the contents of the primary key field of tblauthors, which simply contains an ID number. To display further information from tblauthors (e.g. the author_name field), we need to query both tables simultaneoulsy. We can do this by adding a JOIN clause.

4.3.2.1. Adding JOIN clauses to the FROM field

Various types of SQL joins exist (for further details, see the SQL JOIN section of the W3Schools SQL Tutorial), but the most common is a simple or inner join.

When fields from multiple tables are included in the SELECT clause, we need to indicate which table each field belongs to. We can do this by preceding the field name with the table name and a full stop (there should be no spaces between the names and the full stop):

SELECT
tblauthors.author_name, tblarticles.title, tblarticles.year

In the FROM clause, we connect the table names using the JOIN command.

FROM
tblauthors JOIN tblarticles

However, we also need to specify how the JOIN should be applied, by using an ON clause. (If we don't do this, the query will be interpreted as a CROSS JOIN, which will result in what is known as the Cartesian product of the records in the selected tables - which means every possible combination of them! This is rarely what's intended.)

The ON clause will normally take this general form:

ON table1.field1 = table2.field2

We can see from the database structure diagram that the relationship we're interested in links the id field in tblauthors to the author field in tblarticles, so our ON clause will be:

ON tblauthors.id = tblarticles.author

The full query therefore looks like this:

SELECT
tblauthors.author_name, tblarticles.title, tblarticles.year

FROM
tblauthors JOIN tblarticles ON tblauthors.id = tblarticles.author

If we run this, the query results will now include the author name.

Results of query including JOIN clause

4.3.2.2. Another way of writing JOIN queries

Rather than using the form table_name.field_name in multi-table queries, it is also possible to use a shorthand where each table is assigned a letter in the FROM clause, and this is used elsewhere in the query instead of the full table name. For the query above, this might look like this:

SELECT
a.author_name, b.title, b.year

FROM
tblauthors a JOIN tblarticles b ON a.id = b.author

This is slightly less easy to read, but significantly quicker to type, especially for queries involving many tables and fields.

4.3.2.3. JOIN queries for three or more tables

It is possible to write a JOIN query which draws on information from three or more tables. To do this, we add further JOIN... ON clauses to identify the table and the nature of the join. For example, suppose we want to see a list of article titles from tblarticles, each with the author's name (from tblauthors) and the journal in which the article appeared (from tbljournals). The query would look like this:

SELECT
tblauthors.author_name, tblarticles.title, tbljournals.journal_name

FROM
tblauthors JOIN tblarticles ON tblauthors.id = tblarticles.author
JOIN tbljournals ON tbljournals.id = tblarticles.journal

(The additional line break in the FROM clause above is included solely to increase readability; it is not needed to make the query work.)

The query gives these results:

Results of a JOIN query drawing on three tables

4.3.3. WHERE

The WHERE clause is used for conditional queries, to indicate that records must meet certain criteria.

Various operators can be used as part of a WHERE clause. These include:

Operator Description
= Is equal to
<> Is not equal to
> Is greater than
< Is less then
LIKE

For wildcard searches. Two wildcards can be used:

_ (underscore) can be used to replace a single character - for example, wom_n will find 'woman', 'women', etc.

% (percentage sign) replaces any number of characters - for example, Jo% will find 'Joe', 'John', 'Josephine', 'Joshua', etc.

For a fuller list, see the WHERE Clause section of the W3Schools SQL Tutorial.

Text strings in WHERE clauses (including any wildcard symbols) should be enclosed in single quotation marks (e.g. 'John Smith' or 'John S%'). As in SELECT and FROM clauses, field or table names containing spaces or upper case letters should be enclosed in double quotation marks (e.g. "field name" or "TableName").

To view a specific subset of the results generated by the query given in section 4.3.2.1. above, we could add a WHERE clause. For example,

WHERE
tblauthors.author_name = 'Smith, Alice'

would show us just the articles which have Alice Smith as the author:

Results of query with WHERE clause - Alice Smith

On the other hand,

WHERE
tblarticles.year > 1990

would show just the articles published after 1990:

Results of query with WHERE clause - after 1990

Multiple conditions can be specified by adding ANDs or ORs. For example,

WHERE
tblauthors.author_name = 'Smith, Alice' AND tblarticles.year > 1990

would show us just Alice Smith's post-1990 works (or more precisely, work):

Resuts of query with WHERE clause, using AND

When querying multiple tables, it is also possible to use a WHERE clause instead of a JOIN. You will see this syntax used in the SQL statements generated by the ORDS query builder - see section 3. above.

4.3.4. GROUP BY

GROUP BY can be used to return a list of all unique values in a collection of data. For example, suppose we want to know how many different authors have written at least one article listed in tblarticles. We could use a simple SELECT query for this, but as some authors have written multiple articles, the list would contain duplicates. Adding a GROUP BY clause will group together the entries relating to each author, and give us a list in which each author appears only once.

So, for example,

SELECT
author

FROM
tblarticles

GROUP BY
author

gives us these results:

Results of GROUP BY query

If we want to see the authors' names, we'll need a slightly more complex query, using a JOIN (as the author name information is stored in tblauthors):

SELECT
tblarticles.author, tblauthors.author_name

FROM
tblarticles JOIN tblauthors ON tblarticles.author = tblauthors.id

GROUP BY
tblarticles.author, tblauthors.author_name

gives us:

Results of GROUP BY query including JOIN

GROUP BY is often used in more complex queries involving aggregate functions (e.g. those that count the number of records of a particular type, or give an average value). See the SQL Functions section of the W3Schools SQL Tutorial for more details.

4.3.5. ORDER BY

ORDER BY is used to sort query results by the contents of a specified field.

ASC or DESC can be added after the field name to indicate whether the sorting should be in ascending (A-Z, 0-9) or descending (Z-A, 9-0) order. If neither is included, the sort will default to ascending order.

Suppose we add an ORDER BY clause at the end of the second SQL query from the previous section.

ORDER BY
tblauthors.author_name

This would give us the same list of authors, but now sorted alphabetically.

Results of ORDER BY query with JOIN, sorted by author name

As noted above, query results can also be sorted by clicking a column header on the results page. Clicking the same header again reverses the direction of the sort.

4.3.6. LIMIT

A LIMIT clause is used to set a maximum to the number of results that will be returned. This may be useful when working with large data collections, or where you only wish to see a sample of the data.

For example, a simple SELECT query designed to show us all the contents of tblarticles returns fifteen results. (As noted in section 4.3.1. above, an asterisk can be used to represent all the fields in a table.)

SELECT
*

FROM
tblarticles

Query results - tblarticles

If we add a LIMIT clause, we can reduce the number of results. For example,

LIMIT
5

produces this:

Query results - tblarticles, with LIMIT applied

4.3.7. OFFSET

OFFSET is also used to impose a restriction on the number of results that are returned, by omitting the specified number of results from the beginning of the list. OFFSET can be used together with LIMIT to divide a dataset into sections: for example, entering 10 in the LIMIT field would give the first ten records; entering 10 in LIMIT and 10 in OFFSET would give records 11 to 20; entering 10 in LIMIT and 20 in OFFSET would give records 21 to 30, and so on.

However, there is an important qualification to this: the precise records returned using queries containing OFFSET clauses can sometimes be unpredictable. This is because of a quirk in the way SQL works: there is no guarantee that results will be returned in any specific order, unless the query contains an ORDER BY clause. For example, if we run the following query:

SELECT
*

FROM
tblarticles

LIMIT
5

OFFSET
5

we might expect that the result would be records 6 to 10 from tblarticles. However, what we actually get is this:

Query results - LIMIT and OFFSET

We do have five records from the middle of the table, but instead of records 6, 7, 8, 9, and 10, we have 8, 9, 11, 12, and 13!

Fortunately, this is easily fixed by including an ORDER BY clause in the query. If we add

ORDER BY
id

to the query above, we now get this:

Query results - LIMIT and OFFSET, now sorted

Which is what we were hoping for. For this reason, when running a query that includes an OFFSET clause, it is strongly recommended always also to include an ORDER BY clause.

Note: a bug in the ORDS SQL query page means that queries containing an OFFSET clause will not currently work unless a LIMIT clause is also included. We are aware of this issue, and hope it will be fixed in due course. In the meantime, in the event that you wish to run a query which uses the former but not the latter, simply enter NULL in the LIMIT field. In query terms, this is equivalent to omitting the LIMIT clause.

4.3.8. Other SQL commands

Although only seven fields appear on the SQL query page, a whole host of other SQL commands and functions can be used to construct more complex queries. These additional commands form part of one of the clauses described above - much as JOIN forms part of the FROM clause.

There are many useful sources of information about SQL - the W3Schools SQL Tutorial provides a good basic grounding, but there are numerous other helpful books and websites.

A small number of additional commands are described below, to give a flavour of some of the things it's possible to do with SQL.

4.3.8.1. AS

AS is used as part of the SELECT clause, to specify an alternative column header on the results page. By default, the column header will be the name of the field that the data is taken from. However, you may sometimes wish to tidy up or clarify field names - for example, to add an initial capital, replace underscores with spaces, or to distinguish between two fields with similar names.

Consider this query, which will show us the contents of the title and year fields from tblarticles, plus the author_name field from tblauthors:

SELECT
tblauthors.author_name, tblarticles.title, tblarticles.year

FROM
tblauthors JOIN tblarticles ON tblauthors.id = tblarticles.author

This would give these results:

Query results without using AS

By adding AS and the column header of our choice after each field name, we can smarten up our results table. The revised SELECT clause might look like this:

SELECT
tblauthors.author_name AS "Author name", tblarticles.title AS "Article title", tblarticles.year AS "Year of publication"

Note that as with field and table names, column headers that include spaces or upper case letter should be enclosed in double quotation marks.

If we run the query, the results table will now have our chosen column headings:

Query results using AS

4.3.8.2. Mathematical operators

As well as displaying the actual contents of a database, SQL can be used to perform calculations on the data. For example, suppose we wanted to write a query which gave us the title of each article in tblarticles, its year of publication, and the number of years since publication. The first two bits of information can be taken straight from fields in the table, but the database doesn't contain an explicit record of how long it is since each article first appeared in print.

We can, however, get the information we want by subtracting the year of publication from the current year. One way to do this would be to add 2015 - year to the end of the SELECT clause. The query would therefore look like this:

SELECT
title, year, 2015 - year

FROM
tblarticles

This will give us the correct result - as long as the year is 2015. But if we want to be able to keep re-running the query without having to check whether it's up to date, we might want to modify the query so that it always uses the current year, whatever that happens to be. In PostgreSQL (the specific variety of SQL used by the ORDS), the expression used to do this is (EXTRACT (YEAR FROM CURRENT_DATE)). We use this to replace 2015 in the SELECT clause:

SELECT
title, year, (EXTRACT (YEAR FROM CURRENT_DATE)) - year

We also need to tell the ORDS what to call the new column in the results table. We do this using AS, as described in section 4.3.8.1. above. The complete query will therefore look like this:

SELECT
title, year, (EXTRACT (YEAR FROM CURRENT_DATE)) - tblarticles.year AS "years since publication"

FROM
tblarticles

This gives us the results we were looking for:

Query results including new column generated by subtracting year of publication from current year

For information about some of the more sophisticated functions that SQL can be used to perform on data, see the SQL Functions section of the W3Schools SQL Tutorial.

5. Working with query results

5.1. Exporting query results

The results of a query can be exported as a CSV file. This allows them to be viewed and used outside the ORDS.

CSV is a file format which allows tabular data to be saved as plain text. This makes it a very flexible format: a wide range of software packages for statistical analysis or data visualisation (including Excel, SPSS, and Stata) can read or import data from CSV files.

After running a query, click Export query results as CSV.

What happens next depends on which browser you are using. However, in general, you will be given the option of opening and/or saving thefile containing the query results.

  • In Internet Explorer, you will see a bar at the bottom of the screen asking whether you would like to open or save the exported file. If you click Open, the file will open in your default program for CSV files (if you have Microsoft Office, this is likely to be Excel). If you click Save, the file will be saved in your default location for downloads. You can also click the down arrow at the right-hand side of the Save button to see further options, including Save as, which allows you to select your own location to save the file.
  • In Firefox, you will see a dialogue box inviting you to select a program with which to open the file (again, if you have Microsoft Office, the default is likely to be Excel), or to save it. If you choose the latter, the file will be saved in your Downloads folder: if you wish to save it somewhere else, it may be easier to open the file and then use the Save as function.
  • In Chrome, you will see a Save As dialogue box inviting you to select a location to save the file. After doing this, you will be able to open it.

Whichever browser you are using, the ORDS will give the exported file a placeholder name: you can change this to something more meaningful before saving it.

5.2. Another way of saving query results

Project owners, project administrators, and contributors can also save query results to create datasets for use within the ORDS. For further details, see the later guide in this series, How to view, create, and share datasets. Please note that datasets cannot be created for trial projects.

6. What next?

You may want to have a look at some of the other guides in this series. For a full list, visit the ORDS documentation home page.

You can also find out more about the ORDS service by visiting the ORDS home page, http://ords.ox.ac.uk/. If you have specific queries, you can contact the ORDS help desk by emailing ords@it.ox.ac.uk.

Service area: 

Written by IT Services. Latest revision 15 February 2016