Volume Number: 17 (2001)
Issue Number: 11
Column Tag: Databases

Selections in 4th Dimension

by Elizabeth Delgado

Understanding the Current Selection and the Current Record

When people start using 4th Dimension, or 4D as it is usually called, they are often told they need to learn to "think in 4D." But, how does one "think" in 4D? Understanding 4D's current selections is one of the keys to thinking in 4D. All operations on records in 4D take place on either the current record or the current selection. If you don't understand 4D's use of the current record and the current selection, your 4D based application will seem to have a mind all its own.

A 4D database is comprised of one or more Tables. If you are used to working with SQL databases, this is a concept you are familiar with. If you are used to working in FileMaker, this is a bit different. Each table in 4D maintains a current selection of records at all times. It may be empty or it may contain all of the records in the Table or it may be something in between. But it exists. It always exists. When you display records from a Table in 4D, it displays all of the records contained in the current selection for that Table. If you have performed a Query on the Table prior to displaying the table, then the current selection will contain the results of the query. (Providing you didn't send the results of the query some place other than the current selection, which is another topic entirely.) Aha! You say. It's not so different. It's just a "Found Set" or the results of a SQL Select statement. Well, no. Not exactly.

There is no exact equivalent to 4D's current selections in either SQL based databases or FileMaker. While you may be tempted to think of it in terms you are used to - resist the urge! It's closer to FileMaker's Found Set than to the results of a Select statement because it contains the records with all of their fields and not just the columns designated in a Select statement. It's much more because it exists and can be changed without performing a query or a find. It exists without being displayed anywhere. It can be used and manipulated in memory without being displayed on a form. It can be displayed in records from another table without a relation. Confused? That's normal. Let's see if we can clear that fog a bit.

When you first start up your database the current selection for each Table is empty. If you are using 4D in the User mode, 4D will automatically create a current selection of all of the records in a Table the first time you call for that Table. If however, you are using 4D in Custom Menus mode, you must create the current selection or the current selection will be empty when you first start. The selection you create for that table remains the current selection for that Table unless and until you do something to change it. We will be discussing 4D's behavior in Custom Menus mode, which is how your users interact with your 4D based custom applications.

We will use an example of a Contacts database with 3 Tables: Contacts, Addresses and PhoneNumbers. Initially, the current selection for all three tables is empty. When we select Contacts from the File menu, our menu method calls ALL RECORDS ([Contacts]). The current selection for the Contacts table now contains all of the records in the Contacts Table. If there are 100 Contacts records, the current selection for the Contacts table consists of 100 records. If we select one record to view in the input or detail form, it becomes the current record. What does the current selection for Addresses and Phone Numbers contain? The answer to that is, "it depends."

What does it depend on? It depends on whether or not you have a relation between Contacts and either Addresses or Phone Numbers or both AND on whether or not that relation is automatic or manual AND if it is automatic, whether it is automatic One to Many, automatic Many to One or both. We'll go over each possibility. But first, we need to examine 4D's relations.

Relations in 4D

Relations in 4D are two-way. You create the relation by drawing a line from the foreign key in the Many Table to the Primary key in the One table in the Structure Editor. The relation line always starts at the Many table. That's how 4D knows what the relationship between the two tables is.

Once the relation is established you can make the relation happen automatically for either direction or for both directions, or you can leave the relation manual and only call the one you want when you want it.

Automatic One to Many relations loads the related records from the Many table whenever the related record from the One table is the current record. This changes the current selection in the Many table. Automatic Many to One relations loads the related One record whenever a record in the Many table is the current record. This changes the current record and the current selection in the One table to the related One record. Most 4D developers either use manual relations for everything or automatic many to one but not automatic one to many. The reasons for this will become clearer as we explore the concept of the current selection in depth.

Using an automatic relation in 4D is a way to change the current selection for a table. It is only one of several ways. The following commands in the 4D language also change the current selection and the current record for a table.

ALL RECORDS 
QUERY
QUERY SELECTION
QUERY BY EXAMPLE
QUERY BY FORMULA
QUERY SELECTION BY FORMULA
GOTO RECORD
USE SET 
USE NAMED SELECTION
RELATE MANY
RELATE MANY SELECTION
RELATE ONE 
RELATE ONE SELECTION
REDUCE SELECTION

The selections created by relations are by far the most confusing to the newcomer to 4D. The others are more obvious because you have deliberately done something to change the selection. When you use a relation, whether it is automatic or manual, you have also done something deliberate to change the selection, although you may not realize it initially. To understand why relations affect the current selection you have to understand the concept of the current record.

Lets take a look at what happens when you create a selection in 4D. In addition to each Table having a current selection, each table can have a current record. When you load a record from the current selection into memory it becomes the current record. You may work with that record, change the values in the fields, get values from it, or do any other operation on that record, even without displaying it, because it is the current record and it is loaded in memory.

For purposes of this example, let's say that the Addresses Table has a Many to One relation to the Contacts Table and the PhoneNumbers table has a Many to One relation to the Addresses table. Our structure looks like this:

If there is an automatic one to many relation between Contacts and Addresses, 4D performs the query for you and finds all of the related records in the Addresses table whenever the current record in Contacts changes. For our example lets say there are two related Address records. The current selection for the Addresses table now consists of two records.

If the user double clicks a related Address record to view it and the Addresses table has automatic relations of its own, then the related records for the current record in Addresses load automatically.

If the relation between Addresses and PhoneNumbers is an automatic one to many, then the PhoneNumbers records that are related to the current Addresses record will automatically load. If there are three related PhoneNumbers records, then the current selection in the PhoneNumbers table consists of three records.

Displaying Related Many Records In A Subform

You can display records from another table in 4D simply by placing a subform area on a form and assigning a form from the table you want to display to the subform. Usually you display a list form with a series of records. When you display a subform, 4D simply displays the current selection for the table you have assigned to the subform. It is not necessary to have a relation between the table in the subform and the table the main form belongs to, in order to display records. If there is a current selection for the Table, 4D will display it. Therefore, it is extremely important that you control the selection. Otherwise you may be displaying the wrong data to your users. In our example above, if we did not have an automatic relation between Contacts and Addresses and we did not call Relate Many for each Contact record, we would see the same two Addresses for each and every Contact.

Automatic relations in 4D casecade uphill (Many to One) but not downhill (One to Many). When displaying related many records in subforms, 4D does not automatically load the first record as the current record. It waits for the user to select a record and then, it makes the selected record the current record. Additionally, if the current record in the table in the subform has related many records, they will not load until the subform is double clicked to open the subform record. 4D does load automatic related one records whenever a record becomes current.

Displaying Fields From A Related One Record In A Record

You can place fields from another Table within any form. 4D will display the data from the current record in those fields. Usually you will want to display data from a Related One record. If, however, you have not made the Related One record the current record for the table, you may be displaying incorrect data.

In both of these situations, relations are generally used to control the selection and ensure that the correct data is displayed. However, there are times you may not want a relation. For instance, you may have a Preferences Table with only one record. It is not necessary to have a relation between the Preferences Table and every other table in your database simply to display the information from Preferences. Simply make the one record current and use the data wherever you please. You can also use a query to locate and load the record whose data you want to display.

Using Manual Relations instead of Automatic Relations

Lets assume for a moment that the relations are manual. Again, we have just started the database and our first action is to call ALL RECORDS in Contacts. We then double click to display a detail of the Contacts record. If the relations are manual, there are no records in the current selection of Addresses or Phone Numbers. Why? Because if the relation is manual it is up to you to call the relation to create the selection. If you don't call it, it doesn't get created.

We want to display the related Addresses records within the Contacts record so we call RELATE MANY ([Contacts]ID). 4D loads the related records and there are now 2 records in the current selection of the Addresses table. If we were to now perform a query and narrow our selection in the Contacts table to only three records, how many records are in the current selection of the Addresses table? If you said "2" you got it right.

There were two records in the current selection of Addresses when you performed the query on Contacts. If the relation is manual, then you did nothing to change the current selection in Addresses. Therefore, the same two records are still in the current selection in Addresses and the first record of the current selection Addresses is still loaded in memory. The current selection of a table remains until you do something change it! If you don't change it or clear it, it is still there.

Record Locking in Multi-user and Multi-process Databases

Now that you understand that each table has a current selection at all times, lets add one more rule. Each table has a current selection and a current record in each process at all times. 4D is a multi-process environment. A common use of processes is when a 4D database is run on 4D Server. When in Client-Server, 4D server starts a corresponding process on the server for every process on the client machine. By default, 4D always creates the User/Custom Menus process for each client. 4D Server now maintains a current selection for each table for each user process. If there are 3 tables and 10 users, 4D Server is maintaining 30 current selections in 10 processes.

Multiple processes are not limited to client processes on the server. 4D can handle multiple processes in single-user mode or for each client. A common use is to start a separate process for each table the user accesses. In our example, we have three tables. If we start a new process for each, then each user has three processes. If we have 10 users, the server is maintaining 30 user processes. There is a current selection for each of the three tables in each of the three processes, or 9 current selections per user. With 10 users, we now have 90 current selections being maintained by 4D Server.

Lets take an example where we open each of the three tables in its own process. In each instance we call ALL RECORDS for the table and then select one record to display in a detail form. In each instance, there are automatic one to many and many to one relations. In each instance there is one Contact record with 2 Addresses related to the Contact record and 3 Phone Numbers related to each Address record. The current selections for each process would look like the following.

Why is the current selection for Phone Numbers empty in the Contacts process? Remember that 4D does not cascade the one to many relations. When related many records are loaded, no current record is loaded until one is selected. Therefore, there is no current record in the Address table in our example. Once an Address record is selected, it becomes the current record, but even then, 4D will not load the related Phone Number records automatically. Only after the Address record is selected and displayed in its own input form, will the automatic relation between Addresses and Phone Numbers cause the Phone Numbers records to load. You can view the current selections and the current record for any process in the Runtime Explorer or the debugger window. The example below shows the state of the Contacts process from our eaxmple.

With automatic relations, each time the record pointer moves and a different record becomes the current record in a selection, 4D has to build a new current selection for the related table. As the number of users and user processes increases, this can become a lot of overhead and work for the database engine. Limiting the affect to only the immediately related table takes some of the load off. The rest is up to the developer to handle.

Automatically loading related records can also cause problems with record locking. Only one process can actually write to a record at a time. It's a sort of musical chairs except that there is only one chair. Whichever process gets the record in read write state first, wins. The other processes can look at it but they can't change it. As long as the process has the record loaded in a read write state, no other process can modify it. If you forget to release it and just leave it loaded even after the process is done with it, it will just sit there locked to every other user and every other process until you do something to change the current selection and the current record. It is possible to load a record in read only state and that can solve some of the problems. But sometimes, you have to load the record in read write state. When you do, be sure you don't just leave that current record hanging around after you're done.

OK, now that you are convinced that it is important to keep track of selections and to clear them, how do you do that? If the process ends, the selection will automatically clear. But, if you keep the process alive, you will need to clear the current selection when you are done using it. The simplest thing is to simply clear the selection entirely by calling REDUCE SELECTION([Table];0) This command changes the current selection in the table passed to it in the first parameter to the number of records passed to it in the second parameter. If you pass 0 as the second parameter, then there are no records in the current selection and no current record.

By now, you may be thinking that it would be easier to simply use queries rather than relations to control the current selection. Queries are a perfectly valid way of creating current selections. Both queries and relations have their appropriate uses in 4D.

Advantages of Relations

Queries do not allow you to perform relational queries and sorts. When there is a many to one relation between tables, you can query and sort across tables. Fortunately, you can temporarily make a relation automatic by calling AUTOMATIC RELATIONS and then turn it back off again when you are done. By using Manual Relations you get the best of both worlds. You control which records are loaded and you can flip automatic relations on and off as needed for special operations. If you aren't getting the results you expected, you know you forgot to call a Relation.

Advantages of Queries

When you call a relation via Relate many, relate one OR automatic relations you may affect more than one relation. Relate many (Key Field), for instance changes the selection of records in any table having a relation to the key field. Sometimes, you only want to affect the selection in one table and not another. In that instance, a query is more appropriate.

Take control of the selections in your database. Use manual relations and call AUTOMATIC RELATIONS as needed. Avoid setting automatic relations because they cause excessive overhead and may actually interfere with what you are trying to do. Use queries rather than relations where a relation would affect multiple selections. In time, as you think more and more in 4D, you will find that you know exactly what is going on in each of the tables of your database at any given moment.

Elizabeth Delgado has been using 4D since 1990 and v2.1. She is a contract trainer for 4D, Inc and co-owner of Lizeric, Inc. a custom software development and Mac services company. She has taught 4D's Application Building class since 1999 and has been a speaker at the 4D Summit conferences. She is a contributor to 4D's web site and her writings can be found in several of 4D's "Corners." She is the cofounder of the Los Angeles Area 4D User Group, which Lizeric hosts. Elizabeth can be contacted at EDelgado@Lizeric.com