Evaluation context in Anchor-Buoy model

[bluearrow]

Hi,

I am a little bit lost in the following.

I have a Server/Client setup. External authentication.

I am trying to use the Anchor-Buoy model. I have created several Primary Table Occurrences (PTO), and some Anchor-buoy functional groups.

The following is just an example of the calculation context problem I have.

I have a user table, in that table a calculated global field to autoenter the AccountName. In the Users table, I have an additional field for RealUserName. This way, I know for every user that logs, its real name. I intend to pass this real name to the UserName fields in the data table. Every time a record is created, the CreationUser field in the data table would take the value from the RealUserName field in the Users table.

But, in my Anchor-Buoy model, the PTO table occurrences are not linked with the Anchors, neither among themselves. They are just there for evaluation context purposes, so as to avoid deleting a table I know I have based a calculation in. This is fine, theoretically. However I would like to base my calculation field in those tables, but they are unrelated tables.

- How do you implement it in real world? Should I link all PTOs together among themselves?

- Should I then link each Anchor-buoy functional group with at least one of the PTO as to allow my calculation fields to be based on the PTOs?

- If not, then the only option I see is to duplicate every PTO I need for every Anchor-buoy group that needs it in a calculation field? Is this a correct approach? It seems to me to overkill the graph with so many TOs. There must be another way to solve this puzzle.

I would appreciate your ideas.

Thank you

[David Jondreau]

I'm don't use stand alone PTOs. I use the Primary table as the anchor. If the db is such that I need more than one A-B group for a particular PTO, I choose one group to be the "primary" group.

[bcooney]

I also have abandoned creating PTO_TOs in favor of using one anchor TO for each table. It's much better because they sort together in the calculation dialog.

For example:

CLI

cli_Invoices

cli_Contacts

All non-related calculations use this one primary anchor TO. My layouts based on this anchor TO start with its name:

CLI_Entry

CLI_List

CLI_Find

CLI_Select_dlg (select dialog)

I would suggest a different approach to the AccountName scheme you have above. I usually have an open script find on the AccountName and return the StaffID to a global variable. Then I have an auto-enter calc field in each table, RecordCreatedBy=$$StaffID. This way, if AccountNames change, the IDs remain the same and you can find all records created/modified by that user. There may be other uses for $$StaffID, too.

[bluearrow]

I'm don't use stand alone PTOs. I use the Primary table as the anchor. If the db is such that I need more than one A-B group for a particular PTO, I choose one group to be the "primary" group.

OK. That makes sense. I was trying to use the PTO as the bases of all calculation. Really, it should only be used for internal calculations (for instance, a calculation based on the PTO's own fields, as opossed to fields coming from different TOs).

Now I use the primary table as anchor (as you mention) and as the layout in which all presentations for that TO group are based. I still have a PTO for each and every table in my database, but I only used them for internal calculations and for some Set field steps.

Thank you

[bluearrow]

All non-related calculations use this one primary anchor TO.

That's a good idea. This way, my calculations would either be in a PTO (internal calculations) or the Primary anchor TO (all other calculations).

I would suggest a different approach to the AccountName scheme you have above. I usually have an open script find on the AccountName and return the StaffID to a global variable. Then I have an auto-enter calc field in each table, RecordCreatedBy=$$StaffID. This way, if AccountNames change, the IDs remain the same and you can find all records created/modified by that user. There may be other uses for $$StaffID, too.

This is similar to what I use. I "convert" the AccountName to a FileMaker Id in a Users table, then use this Id for TO relationships and Set field steps.

This way, if AccountNames change, the IDs remain the same and you can find all records created/modified by that user. There may be other uses for $$StaffID, too.

This is an interesting problem. With the new External authentication system in FileMaker, if the AccountName changes in AD:

- The user will not be aware of any issues. He/she of course must know the new network logon name, and will log to the network with this new logon name. He/she will still be able to open a FileMaker hosted file withouth the need to input logon name/password in a FileMaker dialog, as before, but the result of Get(AccountName) in FileMaker will be different. FileMaker privilegues will remain unaltered (of course) as everything else, but this change in logon name in the network wil have adverse effect like the ones that you mention (in Finds, but also in many other areas).

- If the administrator changes the logon name in AD, even if the AD groups and the FileMaker groups remain the same and identical among them, the result of Get(AccountName) would not be the same as before. Thus the need for the FileMaker administrator to be advised by the network administrator that this change is going to take place and change a user table accordingly before the logon name change takes place in the network.

- I do not see any way to relate the new

AccountName to the correct Id in my Users table (except manually modifying the FileMaker Users table, if you have such a table).

- If you use AccountName to visually let the users know who modify, created, etc. a record, then you will be in trouble because the new AccountName and the old one will not be related at all (unless you manually re-relate them in a Users table).

I am not sure if there is an automated way to deal with this issues, but I have not found it. Assuming you have a users table, and that you store AccountNames somehow, I guess you could script that if the AccountName is not found in the table, then return an error, close the file (not let the user in) and send a message to the FileMaker administrator to make sure the new AccountName is corrected in the table. But this means the user cannot access the database until the administrator changes the AccountName in the users table to be the same as in the network.