The purpose of this query is to work backwards in the database, from the lowest level in its core hierarchy to the highest, from a field at the Image Level, up to one at the Manuscript Level. The query will allow you to discover which manuscript has proposed which problematic images—images for which you know the Digital Object ID, but not the manuscript to which they belong. Begin by making a copy of your data; that's the file you'll work with. There are two ways to do this:

The program does the work:

From the top title bar, in the drop-down menu under Maintenance, choose Backup Data; follow that procedure; use the back-up copy to build your query.

You do the work:

Open DS-Access; in the task bar across the upper margin, click on Settings to open its drop-down menu; click on File Locations and look for the location of Data on your computer. It may not give the same location as the example below; this is simply to show the kind of information one is looking for. Make a note of that file location.

Close DS-Access altogether. Go to the location on your computer of the data file, i.e. the path whose filename ends “dsdata.mdb” (that part will certainly exist somewhere on your computer). You’ll end up at a place that looks something like this (in the present example, the computer is running Vista as its operating system; your screen might look somewhat different):

Copy the file, dsdata.mdb, and put your copy someplace else; it's a good idea to include the day's date in the copy's name.

From this point forward the work is all yours.

Click (or double-click) on “dsdata.mdb” to open it; you’ll be offered three successive options to back out of this for security reasons, but in each case, choose the non-default option, i.e. choose consistently to override the protections that Access is trying to offer to you:

Dsdata will open in the so-called “database view” and probably with Tables on the top, or rather, visible. Nevertheless, the object that you want is the one named Queries:

Click on Queries, and you now see this view of the database, with the task that you’ll now want: New (as in “build a new query”):

Click on New and you’re given several options for building a query; the one you want is the Simple Query Wizard, so highlight it and click OK:

Now comes the part where you actually choose the tables and fields that will be of use to you in working “upstream” from the Digital Object ID (which you know) to the related parent Manuscript (which you don’t yet know). The example below includes a number of steps all on one image, but numbered so that you can see the order in which they occur:

1. You use this drop-down list to choose the relevant tables. Start with tblManuscripts (the queries and tables in this list are arranged alphabetically, so just move along until you find the one that you want).
2. This box contains the list of fields that are available in the chosen table (or query), so scroll along until you find the one(s) that you want, and highlight it/them.
3. One by one, click on the arrow that points towards the Selected Fields box.
4. This bounces the chosen field(s) into what will become the Upstream Query that you’re building.

The 3 tables and 7 fields recommended for our current purpose are:

1. tblManuscripts: Shelfmark
2. tblTexts: RangeFolios; Title; GenericTitle
3. tblImages: FolioNumber; Caption; DigitalObjectID

but you can choose more or fewer if you want (just be sure that the minimum is present, i.e. Shelfmark and DigitalObjectID):

Note that the order in which you choose fields is the order in which they’ll appear in your query. Visually, it’s handy to have the Digital Object ID as the last item, but unless you choose it last from tblImages, it won’t occur last in the query results (no big deal; it's your choice).

After you’ve chosen the fields that you want from certain tables, click Next, and then click Next again; leave that button marked in favor of "Detail" since we want the results to show all the fields we've asked for:

On the following dialogue box, you’ll do two things: you'll name the query (here "upstreamQuery" is its monniker, but just like Adam, you have the power to name it whatever you want), and you'll choose to modify the design of the query; then click on Finish.

You now are presented with an impressive view of the query, and if you’re paying attention, you’ll notice that the program has supplied the otherwise missing tables, i.e. tblParts and tblTexts, so that the line between a shelfmark and an image’s name (its Digital Object ID) is continuous. Great. There’s only one action left for you to take, and that is to modify the design of the query. So in the cell that is the intersection between the column for Digital Object ID and the row called Criteria, you’ll type in the worrisome Digital Object ID.

Then you run the query, and you do that by clicking on the red exclamation point in the upper task bar.

The results will look like this:

So you now know which manuscript has that pesky Digital Object ID, and you can move forward trying to figure out where the goof-up lies.

But you're worried. "What if my institution has a whole slew of pesky Digital Object IDs; do I have to rebuild this Upstream Query a zillion times?" No, of course not. The procedure remains somewhat annoying, but it's not completely horrific.

Make a note by hand, or do your standard Microsoft copy-and-paste to retain the information about the manuscript+Digital Objet ID that you’ve just retrieved. Then close the query in the usual manner, by clicking on the X in the upper right corner. The program will ask you if you want to save the results of the query; it doesn’t matter whether you answer yes or no, because, no matter what, you’ll modify the query again for the next pesky Digital Object ID, and then again for the one after that, and then the one after that, and so forth.

So here we are, days later, ready to run the query again. Same as at the beginning: we start by going to the file location for dsdata.mdb, and click it open. As before, the default database view puts Tables on the visible surface, but also as before, it's the object Queries that interests us, so we click on it (remember? we're talking about the panel there on the left, running the length of the form.) The database view now looks like this, so we highlight “upstreamQuery” (or whatever you named it) and click on Design on the upper task bar:

Aha. Back to the view of the query that allows you to specify criteria for the fields. In the following image, because the previous results had not been saved, the crucial cell that is the intersection between the column for Digital Object ID and the row for Criteria is empty; that's because at the end of the last query that you ran, you told the program that you did not want to save its results. Had the results been saved, the cell would have retained the queried number in it, although now enclosed by quote marks (you didn't put the quote marks there; the db did; doesn't matter). In either case, you'll want to type into the cell the new pesky Digital Object ID, then you'll click on the red exclamation point, etc. etc. etc. for as many times as necessary.

Voilà. A bit clutzy but sure and certain; you can absolutely count on the query’s correct information. Remember, though, that you've built the query on a copy of your institution's data. As time passes, and as you polish, perfect and push ahead with the real copy of your database, the copy that holds the query begins to fall out of synch with the real version. You might need to repeat the entire exercise every so often, depending upon the kind of work you've been doing. This explanation of the way to build the Upstream Query will serve as the basis for building other sorts of query as well.