16 articles about Tables and data, in reading order.
Tables and data
Text, numbers, yes/no, dates, option sets, lookups to one table or several, files and images. What each field type stores, the settings it takes, and the control a form shows for it, built on one table.
Tables and data
Make a field required once and every form asks for it. Make it read-only on one form and it's shown but not edited there. Give it a default control and format, and every form and view shows it the same way.
Tables and data
A lookup field links a record to one in another table. Adding one also creates the relationship between the two tables, gives the form a search that finds records as you type, and puts a Related tab on the record at the other end.
Tables and data
Sometimes a link can point at more than one kind of record. A course is booked by a company or by a person. In Parsware that's one field, a lookup to several tables, with a tab for each table on the form and a Related tab on both.
Tables and data
Every relationship in Parsware is one-to-many, made by a lookup, and read as many-to-one from the other end. Here is how to see both directions, how to model many-to-many, and why a record that others still point at can't be deleted.
Tables and data
An option set is a list of choices you define once and use on any table. Each option can have a colour and an icon, and gets a number from your publisher's range that never changes, so renaming is safe and two publishers' lists never collide.
Tables and data
Every table has a State and a Reason. Design the lifecycle your records move through, with a reason under each state, colours and icons that read at a glance, and numbers from your publisher's range.
Tables and data
An auto-number field gives every new record a reference like EQ-2026-00001 the moment it is saved. Nobody types it, nobody can change it, and nobody has to look up the last one used. We imported the Enquiries sample, saved a few enquiries, and changed the format halfway through.
Tables and data
A table's constraints are rules the database itself enforces: no two records may share a code, and no two bookings of one thing may overlap. They hold for a form, an import, a script and two people saving at the same moment. We imported the Court Bookings sample and tried to break both.
Tables and data
A File field holds a document and an Image field holds a picture, each belonging to one record. Add one to a table, attach a file on the form, and see what Save, the size cap and the record's permissions do with it.
Tables and data
A file too big for the environment's database is moved to object storage on its own. The form, Download and who may read it all stay the same, and deleting the record deletes the file.
Tables and data
Choose one field as a table's record image and one as its secondary text, and every list and lookup shows a picture and a second line beside each record's name. Two contacts with the same name stop looking the same.
Tables and data
A table whose records have a parent of their own kind can be shown as a tree, with another table's records hanging underneath, the selected record's form beside it, and a check that stops a branch being moved inside itself.
Tables and data
Load a CSV file into a table. See what is in each column before you import, map columns to fields, and get the rows that failed back as a file to fix, with a reason on each one.
Tables and data
Turn auditing on for a table and every create, update and delete of its records is recorded, with who made the change and what each field was before and after. Leave out the fields that don't matter, and read a record's history in the Audit Log.
Tables and data
When two people edit the same record and both press Save, the second save is refused instead of silently overwriting the first. Here is what each of them sees, and how to carry on.
