Crows Feet In The FileMaker Relationship Graph

From Dwayne Wright PMP
Certified FileMaker Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

Please Note: If you are viewing this page in a news feeder, the images may get munged up a bit or other formatting of the posting may fail. For the best experience, please visit the journal directly by clicking (here).

Ok, let me start off by saying ... that I am not talking about ... those little lines around your eyes that come from staring at the Define Relationship Graph dialog box too long.

Various parts of the relationship graph area carry over (rather loosely I might add) from elements in an entity relationship diagram. An Entity Relationship Diagram (ER Diagram for short) provides a method to document the entities in your database solution, the fields/attributes that define an entity and the relationships between them. In many ways, the FileMaker relationship graph does this as well and much more. If you look closely to where the relationship line connects to the table occurrence box, it spreads out in three prongs (looking somewhat like a crows foot).

Whether the line connects to the table occurrence via a straight line connection or via a crows foot depends upon the cardinality of the relationship. Once again, as a refresher, relationship cardinality refers to the type of relationship such as one to one, one to many and many to many. A crows foot would be an indication the connection to that table occurrence can include multiple records in that table occurrence. So the flow towards that table occurrence is likely a one to many or a many to many relationship. This isn't a guarantee this is indeed true for every record using that relationship but it is a good indication this is true.

HOW SUBTLE THE CHANGES
Look at the two below images from the FileMaker relationship graph, see if you can see what is different and know what prompted the change?

Notice the crows feet do not appear on the patient side of the table occurrence, denoting that a charge record can only be associated to one patient. How does this happen you might be wondering?

The setting of the patient number in the patient table to be an auto enter serial number triggered it!

=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2007 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.



FileMaker Script Debugger Introduction

From Dwayne Wright PMP
Certified FileMaker Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

Please Note: If you are viewing this page in a news feeder, the images may get munged up a bit or other formatting of the posting may fail. For the best experience, please visit the journal directly by clicking (here).

Early versions of FileMaker didn’t have a large selection of troubleshooting and debugging tools. FileMaker was easy to use, elegant and didn’t have any where near the complex design options it does today.

One of the great features of FileMaker Advanced, the Script Debugger allows you to step through script steps in a separate window to help identify where a script may be broken or might need some tweaking. The script debugger feature is available from under a Tools menu, along with options for the Data Viewer, Custom Menus, Database Design Report, Developer Utilities and File Maintenance.

QUICK OVERVIEW OF THE SCRIPT DEBUGGER
Called from the tools menu in FMP Advanced
Always on until you turn it off (and vice versa)
Allows the developer to step through a script line by line
Offers buttons to navigate next, previous, to a determined break point
Debugger can be used effectively with the Data Viewer
You can see interactions of a particular point and time within a script
You can step into subscripts or step out to calling scripts
Great if you have a lot of subscripts and branching actions
Jump directly from the debugger into the script and quickly edit it

So the way it works is that you activate the Script Debugger by choosing it from under the Tools menu. The debugger will appear in a new window but it will be empty. To fill it up, all you need to do is execute a script. As soon as you do that, you will see the script steps for that script show up and you are automatically placed on the first step.

Here you can see the script debugger window with an active script running.

So the idea is that you click one of the step button options to downward through the script and evaluate what is going on in the database at the same time.

ABOUT BREAKPOINTS
With scripts that have a large amount of steps, you may want to jump right to a particular area of the script instead of stepping to it one step at a time. In the Script Debugger, you create a breakpoint where the script can run to and stop. Then you can resume stepping through the script one step at a time. So, the debugger allows you to put in breakpoints and you can quickly go past standard script events and get to what areas of the script you really want to evaluate. Breakpoints can be set while debugging or editing a script and are easy to add or remove. The breakpoints you set are saved along with the script, so they will be there when you want to debug that script again. Obviously, this is much faster than stepping through long scripts one at a time and it helps the developer to focus debugging on specific areas.

ABOUT SCRIPT PARAMETERS AND THE DEBUGGER
In FileMaker, you can have a button, a script or even a custom menu pass data (called a script parameter) to a script that it executes. So you can have two buttons that execute the same script but they can pass a different parameter to that script. Based upon what you pass via the parameter, that destination script will likely operate differently. The same is true for two scripts that both call upon the same subscript. You can view this parameter information in the bottom area of the script debugger.

DEBUGGER PAUSE ON ERROR
Using the FileMaker Advanced script debugger, if you have scripts with a large amount of steps, you may want to jump right to a particular area of the script instead of stepping to it one step at a time. This can be accomplished by setting breakpoints.

Another option you may want to explore is the “Pause On Error” checkbox that appears in the Script Debugger window. The selection of the Pause On Error checkbox in the script debugger will stop at the associated script step that caused the error condition.

This is kind of a dynamic breakpoint, again because the script will run to the point in which you encounter an error. A classic example is when an error message comes up that says you don’t have a valid relationship for a particular task your script wants to perform.

So if you encounter an error in the debugging process, you can then click the Edit Script button to jump directly from the debugger into the script and quickly edit it! Now this feature will work in scripts that have Set Error Capture [On] or those that do not.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.



A READER ASKS: How FileMaker Passwords Get Out

From Dwayne Wright PMP
Certified FileMaker Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

Please Note: If you are viewing this page in a news feeder, the images may get munged up a bit or other formatting of the posting may fail. For the best experience, please visit the journal directly by clicking (here).

A READER ASKS
---------------
in non-office scenarios such as email passwords and online passwords, how does the password get out, or discovered. Are there alot of people spending their time runing password genarators?

DWAYNE RESPONDS
---------------
There are a number of ways that a password can get out but the most prevalent method is via a concept called social engineering. Check out this wikipedia link for more information and research the term on the web.

http://en.wikipedia.org/wiki/Social_engineering_%28security%29
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.



A READER ASKS: A Robust Role Based FileMaker Solution

From Dwayne Wright PMP
Certified FileMaker Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

Please Note: If you are viewing this page in a news feeder, the images may get munged up a bit or other formatting of the posting may fail. For the best experience, please visit the journal directly by clicking (here).

A READER ASKS
I just watched a few of your FMP tutorial videos on your "FileMakerThoughts" YouTube channel -- thanks for them, very helpful.I hate to impose on your time, and I know just blanketing you with a not-so simple FMP question is not all that proper, but truth is, I haven't been able to get any responses from the FMP Forum, and I'm dead tired of reading my FMP 10 Bible (no matter how great and thorough it is) and viewing Lynda.com videos (again, as good as they are). Problem is, I know just enough to get me in trouble. Let me quickly explain...

I know from reading on the internet that my problem isn't unique. In fact, it appears to be quite common. But I cannot find any tutorial that tackles the problem in FMP. I want to create an FMP database for my division's program. Further, I want to normalize the data as best possible (see, I know a bit too much already and I think it's getting in the way of progress). Essentially, I want to develop this DB correctly, the first time.

I wish to have a single PERSON entity table that contains general data (FirstName, LastName, etc.). From there, I need to make each of those people assigned to roles (STUDENT, FACULTY, ALUMNUS, PROFESSIONAL, VISITING LECTURER, etc.). Being assigned a role attaches various related data. For instance, if you are a STUDENT, the Student Record layout would show related ReviewScores in a portal.

I've attempted to complete an ERD, but I cannot get past having a bunch of 1:1 relationships to solve the roles, which I know is a no-no in general and not proper in FMP.

I get TO's (somewhat) and I am fairly comfortable getting around FMP.

So (he asks humbly...), what's the best way to set up this approach in FMP?

Or is it not correct (?).

Essentially, I don't want to create a bunch of tables for each role (that just splits up PERSON). I'm not crazy for thinking this way, am I???

Some specs:

- A PERSON can be part of one or more roles at a time (i.e. STUDENT, FACULTY, ALUMNI, PROFESSIONAL)
- Each role has associated data connected to it (i.e. ALUMNUS has "GraduationDate"; FACULTY has "HireDate" and related Advisees).
- A STUDENT will be an ADVISEE of a FACULTY.

It gets really confusing when I need to create value lists that only dynamically show those in a particular role, as when one would select the proper FACULTY ADVISOR on the Student Record screen.

Again, with all of these roles "in" the PERSON table, am I now in the strange world of self-joins (that I find so difficult to get my head wrapped around)?

Any assistance / help is greatly appreciated.

-------
DWAYNE RESPONDS
I'm not sure how much help I can be on this one either. I would have to spend some considerable time with your solution to recommend something and (with the day job) I just don't do that level of support these days.

Honestly, I simply do not agree with some of the viewpoints about normalization from my fellow seasoned developers. In fact, I think the conversations about normalization do as much harm as they benefit the FileMaker community. The SQL world rules of normalization simply are not absolutes in the FileMaker world.

It sounds like a reasonable approach is to have a join table that has every unique combination of a person and a role. Then you can join this to your staff table and on startup, you can write a routine that finds a person's staff record and then locks them out from viewing any other records. You can have relationships flow through the join table so that it filters associated options on the other side.

Off the top of my head, I can also think of a half dozen other ways to go about doing this including multiple line key fields, security schema using extended privileges and even a heavily scripted routine.

I would recommend that you do some experiments with a new file and work out the kinks there first. Then you can migrate the working code into your solution. Take a peek at some of the FileMaker sites that have a large number of example files like John Mark Osbornes databasepros.com (http://databasepros.com/resources.html).

You might also try the new free FileMaker Technet (http://www.filemaker.com/technet/).

Bringing A Camera To A FileMaker Client Meeting

From Dwayne Wright PMP
Certified FileMaker Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

Please Note: If you are viewing this page in a news feeder, the images may get munged up a bit or other formatting of the posting may fail. For the best experience, please visit the journal directly by clicking (here).

Just thought I’d toss this up quickly on the blog and share it with its readers. I’ve recently begun to bring a digital cameral to all my client meetings. This allows me to take snapshots of the whiteboard illustrations that are created during a meeting. It has become a nice addition to meeting notes to include the picture and comments that come to mind from it.

It also can become a great way to reference back to why you did this or did not do that in a project.

COMMENT FROM A READER BEFORE I MOVED THIS POST TO A DIFFERENT AREA
That is an excellent idea, Dwayne. I also suggest that when you get back to the office, you type up whatever is written on the whiteboard to make it more readable if the handwriting may be hard to understand.
Sometimes the client is outlining his ideas himself and I have on occation had difficulty reading the handwriting after some time has passed and when the subject matter was not so fresh in my mind any longer.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.