The next step up from this is to use start and end times to calculate the number of hours worked:

Here the start and end times are Time fields and the Duration is a Calculation field. Showing the Time fields as hours, minutes and seconds is useful because Bento will assign the current seconds to a time if you do not explicitly set them yourself. For example, if the current time is 13:15:45 and you enter a time as 09:00 because you are only displaying hours and minutes Bento will actually store 09:00:45 which may cause problems with rounding. Therefore it is safest to have Time fields use the Medium display format rather than the Short one.

The Duration formula is:

The End Time - Start Time part is fairly self-explanatory and the division of the result by (60 * 60) is necessary because Bento returns the results of date and time calculations in seconds. Since the result of the calculation should be in hours the seconds need to be converted to hours which is done by dividing them by 3,600 or 60 * 60. Remember to set the results of the Calculation field to be displayed as a Number and with one or two decimal places depending upon how much detail you want to see.

Obviously, if the time recording system is being used to allocate hours to projects or clients additional fields may be needed to store the name of the project and/or the name of the client. Similarly if multiple employees or volunteers are being tracked then a field to store the employee or volunteer names would be necessary.

A more advanced time recording system would perhaps tie in with other Libraries. For example, rather than repeating employee or volunteer names it may be a good idea to use the Address Book or a dedicated Library to store the person’s details and then use a Related Records List to store the time-based details:

Click for a Larger View

For more information about Related Records List please see our guide.

However, because Bento’s related record capabilities are designed to be simple there is an inherent lack of power and flexibility in them and so it may be better to either stick with a one-Library solution or live with some duplicate data and store the person’s name in the main time recording Library. This will allow for the creation of Smart Collections to filter and total records by person and date range which may be useful for calculating weekly, monthly, etc. totals.

Click for a Larger View

Anyway, more details are on the FileMaker site along with the full terms and conditions.

Normal service will be resumed shortly with lots of new tips and articles planned.

The videos are available on the FileMaker web site.

If the above sentence has left you scratching your head then you need to read this article because it will explain what a database is, what a flat-file database is and what relational functionality is.

Flat-File Databases
A database is a store of information. The data is stored in tables and categorised by fields. Each group of information is a record. Consider an address book. The address book itself is a table. The categories in the address book are fields (name, address, phone number, etc.). Each entry in the address book is a record.

An address book may have tabs for each letter of the alphabet so that you can find the person you are looking for quickly and easily. A database can be searched or queried to find the data required. Because data is generally retrieved via a query, the data itself does not need to be entered in any particular order.

The type of database described above is called a flat-file database. This is because it is like a single sheet of paper with all the information on it.

Relational Databases
Explaining what a relational database is is best done by example so assume that you are running a mail-order service and you want to keep track of sales to customers. Essentially you want to store the following information:

• Customer Information: name, address, phone number
• Orders: product, quantity, price, customer
• Product Information: product, description, price, supplier
• Suppliers: name, address, phone number, products supplied

In a flat file database you would need to have a number of tables (two to be exact), each of which holds one set of information. One table would hold information about customers and their orders whilst the second would hold information about suppliers and their products. This is viable if each customer only orders one item and each supplier only makes one product which is a very unlikely scenario.

In reality each table would store a large amount of duplicate information, each order would entail the re-entry of all of the customer’s details. At some point a typing error is likely to occur, for example a customer’s name is incorrectly typed. Now, if you try to look at all the products ordered by a customer you will miss some because of the typing error. In addition, if a customer moves house then you will have to face a lot of typing to update all of the records. Finally, the huge amount of duplicate information takes up disk space, computer memory and will slow down the system.

Now consider the situation where you have a table containing each customer’s details and only one record for each customer. You also have a table containing each order made. Assume that you give each customer a reference number (because customers could share the same surname) and against each order you enter that reference number. You can now relate a customer to an order and if a customer’s details change then you only have to change one record in the customers’ table. Much neater and much more efficient.

A relational database will provide a link between these two table so that you can create a query which will show you the products ordered by each customer.

The same principle can be applied to suppliers and products.

Finally, a link can be made between the orders and the products (via a product reference number) so that a change in the details of a product will be picked up in the orders.

Therefore a relational database saves typing, reduces the potential for errors, reduces the size of a database and makes for much more flexible data management.

Bento: Sitting In The Middle
Bento sits somewhere between a flat-file and a relational database. All of the databases, or Libraries as they are called in Bento, are really flat-file databases and they use one table of data. However it is possible to create some basic relational database functionality via the Related Records Field which is covered in its own article.

Download this video at 400×300 (1.6 MB)
Download this video at 800×600 (5.7 MB)

Click for a Larger View

To solve this I have created an AppleScript which will re-process an exported CSV file and will attempt to re-position the closing quote in the correct position.

Click for a Larger View

Unfortunately there is a restriction which is that your Library should only have one field which contains double-quotes. If you have double-quotes in more than one field then you should probably wait for an official fix.

In addition, before you export your data you need to add a new field to your Library so that the script can find the end of each record. This filed should contain a single character and this character should not appear in the text of any of your fields. This is most easily achieved via a Calculation field:

Click for a Larger View

The name of the field is irrelevant. but in the above screenshot it is called ‘EOR’ which is short for ‘End of Record’ and I have used the pipe ( | ) character to identify the end of each record.

Once you have exported your CSV file you need to process it using the Double Quote Fixer script. Simply double-click on the Double Quote Fixer file (downloadable below) which will open the file in an application called Script Editor.

Click for a Larger View

Just below the grey comments you will find some configuration settings which you may like to change.

Click for a Larger View

• Remove_Carriage_Returns will strip out any carriage returns. This can be useful if you are, for example, processing text which will be imported into something else which does not handle multi-line CSV records well. The setting should either be true or false.
• Record_Delimiter is the character you used in the record delimiter field as described above.
• Double_Quote_Symbol is a symbol which the carriage returns will be replaced with temporarily. If you use this character in your text you need to change it to something else.
• Double_Quote_Opening_Closing_Symbol is another symbol which is used to temporarily replace carriage returns. Again, if you use this character in your text you need to change it to something else.

No not change the New_Line_Character.

Now you can run the script via the Run button in the toolbar or the Run command in the Script menu. You will be asked to select the original export file and then when it has been processed you will be asked where the fixed file should be saved.

Please note that the process can take a while is your CSV file is large so please be patient.

Download the Double Quote Fixer.

Import the two files into Bento which will result in two Libraries, in this example called Patients and Appointments. Ensure that during the import process you set the field types of the fields being imported properly:

Click for a Larger View

Now that the data is in Bento the two Libraries need to be linked via Related Records Lists. Because there are fewer patient records than there are appointment records it will be quicker to work through the patient records and relate the appointments to them rather than working through each appointments and relating a single patient to each.

In addition, since when you add existing data to a Related Records List you can search for the records you want to add we need a way to quickly find the appointment records for each patient. At first it may seem that the PatientID field would be ideal for this but since it is just a number, searching for ‘1′ would also return records where the appointment date contains a 1. Therefore the PatientID field needs to be made unique and this can be achieved via a Calculation field:

Click for a Larger View

The Calculation field above is simply appending the PatientID field to some text, ‘PID’, resulting in values such as ‘PID1′, ‘PID2′, etc. These values will be unique to this field so the Appointments Library can now be searched with records being returned for relevant patient only.

In a form in the Patients Library add the PatientID and the Patient fields. Also add a Related Records List based on the Appointments Library:

The Appointments Related Records List needs to have the PID field and the Appointment Date field displayed:

Click for a Larger View

Now it is possible to work through the patient records and choose the relevant appointment records for each:

Click for a Larger View

Once this process has been completed the PatientID fields can be deleted from both the Patients and Appointments Libraries and the PID field can be deleted from the Appointments Library:

Any new appointments which are logged against a patient will automatically be linked by Bento.

The way to get around this is to follow these steps:

1. Export the data from Bento as a CSV file.
2. Open the CSV file in a spreadsheet such as Numbers or Excel.
3. Re-order the columns in the spreadsheet.
4. Export the data as a CSV file from the spreadsheet.
5. Import this new CSV file into Bento, creating a new Library.
6. If you want to, delete the original Library and rename the new one to give it the original Library’s name.

Now, whenever this Library is exported the fields will be in the correct order.

Unfortunately there is no printed version available, even in the boxed version. If you want to print your own version but would like to reduce the paper usage, remember that you can always go to the ‘Layout’ print settings and change the number of pages per sheet and two pages per sheet is still readable as long as you have reasonable eyesight or glasses.