Search Project Mgmt
Search FileMaker Blogs

Thank you for visiting the FileMaker Thoughts blog. I recently moved this content over from my blogger account. Hope you like it! When you get a chance, check out the centralized search feature for all the FileMaker blogs found along the right side panel. It is quite handy!


Thursday
Jul242014

Potential Issue With FileMaker Global Fields

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

There is a potential problem with the use of global fields (fields with the storage option of global set) in multi-user solutions. Global fields are designed to have the same information on each record. So that is to say if you change the contents of a global field in one record, you have made that change on all the records. There are a number of unique ways you can implement a global field in a layout, calculation, relationship or script. All of these uses can change when the solution goes from a single user setup to a multi-user setup.


What happens is that a change to the data inside of a global field, in a hosted database, only affects the records for that particular user. A common term for this effect is that the change is session specific. Anyone else using the database at that time will see the information that was in that global when they first opened the file. Also, the change of information in that global field will be temporary and will not stay with the user when they close the hosted file. Back to the user that changed the information in a global ... if they close the file and reopen it ... the global will contain the original information.

To make matters a little more complicate, the global field can change its behavior based upon how the file is being hosted. A FileMaker file can be hosted via FileMaker Server or Peer To Peer. If the solution is run on a machine that is using the workstation version of FileMaker (commonly referred to a peer to peer), a global field can operate in 3 different ways based upon ...

1) if the solution is on a machine that hosts the solution ... but ... no other users have signed on yet.

In this case, when the host user makes a change to a global, it is going to stick. From that point forward, that will be the reference information for that global when new people open the database file.

2) if the user is on a machine that host the solution ... and ... the host makes the change to the global field

In this case, when the host user makes a change to a global, it is going to stick. From that point forward, that will be the reference information for that global when new people open the database file. If a guest is logged in when the host changes the global, the guest will not see the edited information until they log off the database file and then log back in.

3) if the solution is on a machine that hosts the solution ... and ... a guest makes the change to the global field

In this case, the changed information inside of the global field will only be seen by that particular guest user during the time they have that file opened. If they close and reopen the file, the data inside of the global will revert back to it’s original content.

The most common way that a FileMaker file will be hosted, is via the FileMaker Server. This means that anyone that logs into the solution will be a guest. The information that is in a global field when the server opens the solutions becomes the default for all guests. The only way to change the default information in a global is to close it from the server, open it with a workstation version of FileMaker, change the information in the global, close the file and reopen the FileMaker file with the server version.

When a FileMaker file is being hosted via the server and data is added to any global field, the information will be for that user only and valid during that session. This can be a very good thing because the global can act like a variable to control script branching, build primary keys in relationships and even control screen display.

** Please note that many developers do not use global fields this way any longer with the ability to set variables using a script or calculation. **

Counters that use global fields will not work in multi-user FileMaker environments. This is because each users changes to a global fields in a multi-user environment will not be seen by the other user. So one users increment from 787 to 788 will not be seen by the other users. To them, it will still say 787. You will likely want to use some sort of self relationship ( with a script that sets a field equal to itself plus 1) when trying to build a counter for multi-user environments.

In Summary ... the multi-user global field issue isn’t really an issue. It is more of a behavior. You can use it to your advantage and you can easily fix any problems that arise.

=
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.

Wednesday
Jul232014

A Reader Asks: Access To FileMaker Field Creation

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

A READER ASKS
You don't know me but I have found your site very useful from time to time.

I have the dumbest problem in FileMaker, and although I am an experienced FM developer I am blanking on the answer (or if there is an answer), so I am hoping you have the time to reply to this email.

I have a request for a set of users to be able to access the layouts in a particular file, but *not* be allowed to create new fields. I can see all the toggles for *accessing* this layout or that, or this field or that, but nothing that explicitly prohibits a user from creating a *new* field on their own.

If I give them access to the table, then they can add new fields right? Unless I only give them view access, but that would stop them being able to create new records as well. Is there an answer to this?

The users need basic data entry access in all tables, they "need" (they think) access to layouts so as to be able to make their own letters and lists, and thus layout view. But they have this nasty habit of creating new and interesting fields that screw up the whole database, so how can I stop them from doing that?

-------
DWAYNE RESPONDS
That isn’t a foolish question at all. I had always assumed that the ability to create fields was exclusive to the full access privilege set. I searched a number of resources but couldn’t find confirmation to this in any of them. In the brief testing that I did, I could not find any privilege set configuration, other than full access, that allowed for the creation of a field.

Here you can see a snapshot of the layout modification privilege set setting that I used to allow users to modify layouts but does not have access to field creation. Via the custom settings, you can get more granular and configure which specific layouts can be modified by a particular privilege set.
=
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.

Tuesday
Jul222014

Commenting First and FileMaker Scripting Later

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

This is a follow up to the "Formatting In FileMaker Script Comments" post. Basically, the same message but taking a different angle at describing the process.

FROM MY FUTURE CUSTOMER: I need to create a "template" of events related to a company which has been targeted for a campaign. I am thinking: Call 1 (date); Mail 1 (date); Call 2 (defined as "Call I date + 7"); Mail 2 (same as Call 2 Date); Call 3 (call 2 Date + 10); Mail 3. (Call 3 date +10). Mail 4 (Mail 3 date + 10); Call 4 (final) = Mail 4 date + 7.

Here you can see the future script with the comments only. It will be interesting to see how it will evolve as the script steps are filled in.

Here you can see we are capturing the primary lead id information into a variable. This is because we will want to have each new future event record tied to the current contact. We also freeze the current window because we don’t want to put the user into interface shock as we change from record to record.

Here you can see that I’ve reorganized the comments. This is because it made more sense to group them together by the type in case you need to tweak the entire set by group.

Here I have also added a number of things I hadn’t thought of including ...

- capturing the linked campaign ID and name to variables
- capturing the linked staff ID to a variable
- changed the name of the first call / mail to be today + 1
- set a variable equal to the current date

then I actually populated the first event with its needed script steps. I did a smoke test run the script and it worked just fine. Since I’m using a copy of FileMaker Advanced, I copied and pasted this working code to the other areas and tweaked as necessary. The tweaks including updating the event date and event type. Below you can see much of the final script. It ended up being a little more detailed than I initially thought but that is common when you start to script something.

You can click the above image to view it better.

=
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.

Monday
Jul212014

Replace Command For Missing FileMaker Primary Key Data

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

As you know, it is recommended that every FileMaker table have a field that uniquely defines that record with an auto enter, unique, sequential data string. This is often called a primary key field.

Ok, why would you want to have a field auto enter a serial number on each new record? Well, two reasons come to mind. One is for your use in searches or uniquely identify one record from another. Another reason is for the “under the hood” programing of FileMaker relationships. A huge majority of FileMaker relationships in any solution will involve a unique record id in at least one side of the relationship!

Now, let us chat a bit about the primary key field, otherwise known as the record id field, is a field that uniquely identifies each record in a file. It is almost always used as a parent key field. It is defined as auto enter data option when a new record is created and should be sequential. It can be saved in text or number format but I prefer text format myself. The primary key field should never be edited because it can break any existing child records. I do recommend that every table have an auto enter, sequential, non editable primary key field within it.

If your primary key field is empty on some records, it’s likely because you did not select that option when importing new records into that table. Not to fear, you can use the replace command to do this for you after the fact. Replace is a command under the Records menu that can be used to replace the contents of a field in all records of the current found set. You can exchange the fields contents with a data string, an incremental serial number string or a calculated result.

WARNING: Replace Field Contents script step is very flexible, very powerful and potentially very dangerous if misused. There is no undo for the replace command.

=
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.

Monday
Jul212014

Formatting In FileMaker Script Comments

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

In one of the adatasol FileMaker podcasts, a script creating mind set was discussed that entailed the idea of adding your script comments first, before your script steps. Comment out everything you want to do in a script first and then fill in the blanks with your actual scripts. The idea is that you are modeling your script a head of time and then you have it automatically documented when you are done.

I’ve been doing a lot of that lately and I might become a pretty big fan of it. Not sure it will be on the level of learning Anchor/Buoy, but it will probably be up there. So a stray thought struck me in the last big script that I did ...

Wouldn’t it be cool if you can have some formatting control over your script comments?

This could be very interesting ideas. Take a peek at what a script could look like if you had some control over the formatting of its comments. This is just a small snapshot of the script that converts a lead record in InBizness SOHO to a client record. Any records that are related to a lead are converted over to the new contact record as well. So the lead history travels to the new client as well.

PREFIXING
In bold text, you can prefix the script comments for a particular section based upon that sections primary focus. In this example, you can quickly identify the sections of the script for Error Checking, Record Creation and Reassigning Related Records.

COLOR CODING
Bold red is an obvious choice for error checking. I could see that quickly becoming a “best practice for formatting script comments. I used blue to be color for creating of records and green for conversion subscripts.
Here you can see how neatly a text formatting tool bar would fit in the Set Comment script step dialog box.
=
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.