Thursday
Aug272009

A READER ASKS: Customers And Latest Order Date

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

APPENDIX 3: A Reader Asks

A READER ASKS
Any chance i can pay you for an answer to a filemaker question? :)

(found your blog, drilled through it but didnt find an answer) (same to be true for a lot of the filemaker forums)

I have a simple need:

Customer Table
Order Table

I simply want the date of the most current order. How?

After sorting the ORDER table I tried calculating the max, and latest, without success.

-------
DWAYNE RESPONDS
By all means, you can always pay me for an answer! It is the only way I can keep Peanut Butter on the shelf. (grin) If you want to do a quick donation on one of the blogs, that would be nice. We can always setup a more formal support system with Virtual One On Ones or consulting services. I have a large number of clients that purchase a support bundle and then contact me when they need the occasional help getting over a FileMaker design speed bump.

About the latest order issue, there are a couple ways to do it but one is ruthlessly simple.

- Pull up the relationship dialog box between the relationship from the customers table to the orders table.
- Under the Orders table, choose to have the relationship sorted by order date descending
- Put the order date field on the Customer table layout



Since the relationship is sorted by order date, the field will always show the date by the most current order.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2009 - 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.

ADVERTISEMENT ==================
Help support this blog by considering a donating to its ongoing growth. For more details, please visit http://www.dwaynewright.com/donate.html

Monday
Jul132009

FILEMAKER: Delete Parent Table Equal Delete Of Related Child Records?

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

A READER ASKS
Two tables connected with the auto delete related records setup, what happens if the parent table is deleted from the graph entirely? Are the records that were related to the parent table deleted by the action of the table being removed. What about if just the table occurrence itself is removed by not the table?

-------
DWAYNE RESPONDS
When you define a relationship, you can define an option to delete related records when the parent record is deleted. This is a great way to cleanup orphaned related records when the parent record is deleted. It is a nice feature but I do ask that you consider the consequences of this feature about before implementing.


I haven’t run across a delete parent table with the associate related delete option enabled in the “real world” but your question is an excellent example of some questions that you should consider before implementing this setting. In my research of FileMaker blogs and books, I didn’t find this particular question addressed. So I decided to build an example file, set it up with the exact settings you described and give it a go. In the movie linked below, you will see that my tests seem to indicate that related records ARE NOT deleted if the parent table is deleted.

Here are some links to other posts that might be of interest in regards to this topic...
Cascading Deletes

This setting will delete any records in a child file related to a parent record.


There is a related movie on this topic! CLICK HERE!

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

© 2009 - 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.

ADVERTISEMENT ==============================
Looking for a robust FileMaker CRM template to manage your business? Check out the InBizness product line at http://www.dwaynewright.com/solutions.html.

Thursday
Jul092009

A READER ASKS: Security And The Relationship Graph

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 09: The Separation Model

A READER ASKS

We have multiple files in our FileMaker solution. We have instances where a user has full access in one file and does not have full user access in the second file. In regards to our mixed access users, looking at the relationship graph for the file they have full access to ... what does the relationship graph look like?

-------
DWAYNE RESPONDS
I have to admit that I don’t have a lot of solutions that use this type of configuration. I decided to try a “real world” test on this and my results seem to indicate ...

the user doesn’t seem to have any relationship graph restrictions in a mixed setting mentioned above. Check out the movie below and feel free to share any experiences you may have.


There is a related movie on this topic! CLICK HERE!

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

© 2009 - 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.

ADVERTISEMENT ==================
Help support this blog by considering a donating to its ongoing growth. For more details, please visit http://www.dwaynewright.com/donate.html

Saturday
May232009

FILEMAKER: Join Tables Explored

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 05: About Relational Design

The idea behind FileMaker join tables is that you have two (or more) table occurrences that are linked together via a middle table occurrence. Because FileMaker relationships can flow from one table occurrence, through another table occurrence to a table occurrence on the other side, you can have an almost unlimited number of interlocking relationship combinations.


The join table is designed to support many to many relationships. In a many to many relationship a collection of records in one table occurrence can share a relationship to many records in another table occurrence. Here I have a few illustrations that might help.

EXAMPLE - A car mechanic may have worked on many cars and a car may have been worked on by many mechanics. So if you wanted all the cars a mechanic has worked on and all the mechanics that have worked on all those cars, you might have an impressive list.

EXAMPLE - A movie may have many actors and each actor may have been in many movies. So if you wanted a list of all the actors in a movie and then a list of all the movies those actors had been in, you would probably have a large list.

EXAMPLE - A high school teacher may have many students and each student may have many teachers. So if said you wanted to find all the students for a particular teacher and all of their associated teachers ... you would get a very big list.

So a join table will likely have a primary key field but it isn’t used for much. The power comes from the collection of foreign key fields it contains and how they interact with the data. Normally, a join table will have a foreign key field for each table it links, to support the join operation. When you are talking about a join table setup, it is not uncommon to call the central table the join ... obviously .. and refer to the linked table occurrences as the outer tables. This is because they circle the central join table in an outer orbit.


Here you can see a classic join situation where I have campaigns, clients and staff table occurrences linked together. Notice that I have client, campaign and staff foreign key fields in the table. Using this way, I have a large many to many relationship opportunity. From a staff member record, I can see all the campaigns they are linked to and see what clients might be linked to those campaigns (the reverse is true as well).

In fact, the above setup would even support the ability to have the same staff member assigned to the same campaign multiple times! This may come in handy if the staff member is performing multiple roles within the campaign.

Because FileMaker table occurrences can see each other through the join, when you drag a field into a portal, you can use a field from a table occurrence other than the one defined for the portal! The portal shows you the join records but the field in the portal row can be from the table occurrence on the other side of the join and can show you the appropriate data through the join.

LIST OF WAYS I’VE USED JOIN TABLES
Here is a quick list of some of the ways I’ve used join tables ...

- Invoice Line Items, linking invoice records to inventory records

- Line Items, shared by invoices & purchase orders linking to inventory records

- Phone Number, linked by clients, leads and vendors

- Payments made, to support one payment to one invoice, one payment to many invoices, one invoice with many payments or even payments that have not been applied to an invoice yet.


The most classic example of a database join is a products sold table / table occurrence. This TO (table occurrence) would reside between and invoice TO and an inventory TO. It would hold all the unique line items sold on an invoice. It would join the Invoice TO and the Inventory TO together in ways that could not be done directly between the two files ( or at least not done easily ).

Here are some links to other posts that might be of interest in regards to this topic...
Join Relationship
EXAMPLE: Join Relationship
EXAMPLE: Indirect Related Data Via A Join
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2009 - 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.

ADVERTISEMENT ==================
Help support this blog by considering a donating to its ongoing growth. For more details, please visit http://www.dwaynewright.com/donate.html

Sunday
May172009

FILEMAKER: The Separation Model And Run Script With Full Access

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 09: The Separation Model

This posting was inspired by a series of posts on the FileMaker Tech Talk forum. If you are serious in honing your FileMaker development skills, please consider joining the FileMaker Technical Network and enjoy a wide array of support options like the Tech Talk forum, member only web site access, free software, exclusive learning materials and more. Membership runs just $99.00 a year and I couldn't recommend it enough.

--------
In a separation module situation, the user interface layouts reside in one file, the actual data resides in another file and external data sources allow the two files to work in unison (with some exceptions). One exception is the ability to run a script with the full access setting due to its dependent nature on where the script resides.

QUICK LINKS TO RELATED ARTICLES
The Separation Model
External Data Source
Manage External Data Sources
Get(PrivilegeSetName) And Scripts With Full Access
The Get(PrivilegeSetName) Function
Substantive Privileges Explored
How Scripts Are Called
FileMaker 9 Server Only Runs Web Compatible Scripts
Robots

To recap, the "Run script with full access privileges" checkbox on a script is dependent upon actions within the file it resides. Executing a script to delete records within the interface file with "Run script with full access privileges" activated will not override the lack of deletion privileges within the data file for that user.

OPTION ONE
Run the delete script within the data file and have its "Run script with full access privileges" checkbox selected. The script in the interface file calls upon the data file script and then returns. Depending on the number of records affected (shown within the interface file), the user might see what is going on. Somewhat akin to when Toto pulls back the curtain on the Wizard Of Oz.

OPTION TWO
Add the ability for the user to delete records in the data file but add conditions that can only occur within a scripted process. This is done by linking the ability to delete to a TRUE calculated result. (add link where I discuss this). The most elegant way to do this is to link the calculation to a global value set by the script, either a global field that can be seen in the data file or setting a global variable within the data file.

REMEMBER: Global variables ... like the "Run script with full access privileges" setting ... are file dependent.

OPTION THREE
There are a collection of options here that can get pretty messy. One is to temporarily re-login the user with a delete privilege in the data file for the duration of the script. Another option is to NOT delete the script but flag them for deletion. Later on, a user with delete privileges or a batch script (run by FileMaker Server or a robot) actually deletes the record.

ALL METHODS BREAK THE SEPARATION MODEL MYTH
Adding in of the listed options (and likely those that I didn't list) will break the myth that separation model implementations are seamless upgrades. That whatever the coding update to a solution, all you need to do is pop in a new interface file and you are good to go.

In some cases, the developer can go onsite (even virtually) and add the needed schema changes to the LIVE data file. This can be done outside of traditional business hours, after a proper backup has been done. The "bag of hurt" method can be adding the schema choices to an empty data file and the reimporting all the data records again. Both methods have some level of upgrade risk involved and those risks should be measured properly before executing.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2009 - 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.

ADVERTISEMENT ==================
MacUSA provides website and FileMaker Pro hosting services. Utilizing the highest performance web and FileMaker servers. We make FileMaker database hosting as simple as possible. Mac USA Technical Support has been voted the best by our customers. FileMaker Server hosting for your FileMaker web hosting needs supporting FileMaker 10 down through version 5. Hosting FileMaker Pro databases for Instant Web Publishing and Custom Web Publishing including PHP, XML, ODBC, and MySQL access. Use Promo Code dw0904TB for FREE setup (a $25 value) when signing up for your FileMaker Hosting services. Offer expires 6/30/2009. http://macusa.net