Within your database, you could have literally any number of tables - in Method, there are potentially hundreds of tables contained in your database.  For example: you might have a table for Customers, one for Invoices, and so on.  The takeaway from this is tables typically deal with a single topic per table.  The information in each table is divided into fields

But what do we mean by fields? Well, the table is divided into columns and rows, like all tables you’re familiar with.  In Method terms, the value of the column is considered the field and the value of the row is considered the record.  Let’s explain in further detail.

Remember how each column in our pretend customer table was labeled (first name, last name, and email)?  It’s helpful to think of fields as the kind of information you are displaying and records as the collected value of that information.  So if the record only has one field, say Customer First Name (a text field type, for those keeping track), the value of this record might be “Bob”.

It’s important to note here that Method assigns a unique number to each record in a table (in database lingo, it’s commonly called a “primary key”), so no matter whether this record contains just “Bob”, “Bob Crenshaw, 123 Main Street, 555-1234, whose favorite color is blue”, it will always have the same record number that was assigned to it upon creation (say, 42) - a sequential number that cannot be changed.  Even if you delete the record, that unique number will never be used again in that table - the next record created after that will be assigned the next sequential number (say, 43). 

The other interesting thing about tables is that they might not operate independently of one another.  Remember when we talked about the dropdown field type and how it pulls a list of values from a table?  That’s just one example of how tables “talk to” one another within Method.  

Think about it this way: the Activities table is unique to Method because it’s a CRM table that doesn’t have an equivalent in QuickBooks, but within that table, there are a number of fields that point to other tables that do have QuickBooks equivalents.  For example, there is a contacts field within the Activities table that points to (or pulls information from) the Contacts table.  This allows you to access information from all over your database when you’re building a screen based on a particular table (which sounds complicated, but we’re going to explain these concepts further as we go through this manual - right now the plan is just to get you thinking in these terms!).

Did this answer your question?