Sum in reports

Easy - just do a textbox with =sum(nameofthefield)

BUT

make sure it's in the Report Footer - not the Page Footer!

Searching for a blank field

Sometimes you want to search for fields which have been left blank - say you've put the date a job was completed on.

All you do is add the criteria of Is Null (the space is important!!!) and it'll do it.

Personally I'd tend to suggest using a Yes/No field to record if it's been paid for this sort of thing, but sometimes client needs mean you need to record the actual date.

Versions of Access

Here's the version screenshot (assuming it actually shows - sometimes blogs and stuff can be tricky to show images):

Specifying Queries

This is a good idea.

Your database needs to specify (i.e. plan) the queries you're going to be using. This means it needs to

• say what the query will be called
• say what fields will be used in it - and which table they will come from

e.g.

qryInvoice
Csutomer ID - from tblCstomer
BookingID - from tblBookings

etc...

Input Needs

You probably have things like

• input masks
• drop down boxes
• calendar controls
• parameter queries
• forms

Fine. I need a section which gives a brief overview of data input needs. All the evidence for this is probably already there, but this section needs to bring that all together and summarise it (bullet points are fine).

I need:

1. what data is going to be inputted
2. who is going to do the inputting (at the client)
3. where are they going to get the data from
4. how is the input going to be done - cross reference to all the screenshots of stuff you have (the list above) with page numbers

I would have a section for this, probably towards the end of the Implementation section (somewhere around security) called "Input Needs". Lots of cross referencing to the stuff you've already got is just fine.

Hannah says what are Standard Ways of Working?

Another good question Hannah. I hope you'll continue to ask questions long after you've left us.

Standard ways of working need to be proven for most portfolios. This simply means do things the way they should be done - the "industry standard" ways of doing stuff. Like:

• sensible file names, using version numbers etc... Include your documentation etc... as well as whatever you're producing
• sensible sheet names or names for queries, reports, tables etc... using standard methods (like: tblPokemonCharacters or qryYellowFruit)
• sensible file structure - using folders effectively to organise work
• backing up an using appropriate storage

For Project Management you might also include elements which show that you've used standard ways of working for group projects such as:

• use of agenda, minutes etc... to schedule meetings
• use of project management software to plan - e.g. Gannt charts and resource assignments using Open Workbench
• effective use of e-mail, letters, synchronous chat etc... to manage work
• use of collaborative documents to allow multiple people to work on the same document (for example, user guides etc...)

For the final mark in the row you'll need to be answering the question: Why did I/we do this?

Justification of Database software

This is a simple three marks to get.

Check the markscheme first - it's AO2 Row 3. Then this is what I'd do:

1. Clearly state exactly which version of Access is being used. Without this it won’t get 1 mark
2. Say that they already have it and so don’t need to buy any new software in
3. Say that it’s the only bit of database software they have so there isn't a real alternative
4. If anyone in the client organisation has any familiarity at all with it then say so – they may have used it at school or in another job for example or done some very basic training with it
5. Say that you need a number of tables for different entities (name the entities) and therefore need an RDBMS (a Relational Database Management System)

You could add about the ability to build forms to create a user friendly interface using things like drop down boxes, calendar controls etc… and use security features etc… Linking this to client needs (briefly!) isn't a bad idea.

Database and Spreadsheet Files

The people who produce the textbooks you have for Spreadsheets and Databases have put a bunch of free resource files online.

These might be handy to use rather than having to type stuff in by hand.

The files are organised by editions of the book - you have the third edition of both books. It doesn't mean the other files wouldn't be useful or interesting, just that they might not be quite so useful or interesting.

Normal, Extreme and Erroneous

And that's just the usual Year 13 class...

So, this is about testing and test plans.

When you create them - and this applies equally for unit 10 (spreadsheets) and unit 3 (databases) you need sets of test data. That means data you want to use to test that your system works properly and check that it gives you the expected results.

You need to be really clear about the data you're going to use - that means I expect to see precisely what you're going to input - 10 in that box, Blue in that option and so on.

Now, the data needs to include 3 types:

• Normal - this is data which you would expect. Standard data that the system should accept without any problems
• Extreme - this is data at the extreme range of acceptable. You sometimes see this called 'boundary values'. You need to test each side of the boundary - so if a data value should accept values from 1-9 then I'd expect to see 9 and 10 being tested; if it has to be a maximum length then I'd expect testing at that length and one above the length and so on
• Erroneous - this is data which is clearly wrong - data which should never be accepted by the system. You want the system to reject this data. So, if I wanted a value 1-9 then I'd test things like 14, 473535, -1, 0, 4.5 and red.

OK?