Prohibit modification of related value

[trevorg]

If anyone can help me on this it would be greatly appreciated.

Two databases (A and which are 1 to Many.

If a number value exists one time per record in A, and the users have rights to create/edit/copy that number field within A, yet the number field is shown in database B but we do not want the users changing that value there, but we DO want them to be able to copy the value and search within the value.

Locking the field on the layout is no good. (can't copy/search it)

Can't set restrictions via access privileges on the value in database A because there shouldn't be any restrictions within database A

Can't set any access privileges in database B because the field doesn't exist in database B

Does anyone know how can this be accomplished?

The only workaround I've found is creating a calculation in database B that pulls the related value from database A. But doing this a lot increases the size of the database! (conscious of the 2 gig filemaker limit per table)

[kenseye]

You could create a search layout that allows entry into the field for search purposes but still have no access in a view layout.

[trevorg]

Thank you for the reply. I use search layouts throughout for this reason, however, this field has a requirement of being copied also, and that is not possible on a search layout.

I'm thinking this is another "limitation" of FileMaker. I hate those!

[Keith M. Davie]

"...however, this field has a requirement of being copied also..."

Ok. Generally, if something is going to be copied it is going to be pasted somewhere. Can this not be handled with a ScriptMaker script? Even if it is to be copied and then pasted in an application different from FMPro you should be able to paste it into a layout/field where the client can copy.

[Vaughan]

Following on from Keith... create a "Copy" script that changes to an unlocked layout, does the copy, then returns.

[trevorg]

Thanks guys. I completely forgot about a simple script. I guess I was searching for the a difficult solution.

The script will work just fine.

[Rigsby]

I think you were onto the best solution with your calculation idea, but do not create this in file B, create it in file A. E.g. Field 2 = Field 1. Now simply display this calculating field in File B.

I think this will give your users a lot more flexibility and will save you from creating more scripts. If you script simple commands like copy and paste, you can cause problems for users. The reasons for this are: Either you have to script these commands throughout your entire solution, or users are faced with inconsistency in you solution. I.e. If I copy something on layout A, then logic tells me I should use the same command to copy something on layout B. you also have the problem of removing the keyboard functions for such commands, which will annoy users who tend to stay away from the mouse (i.e. power users).

[trevorg]

Thanks Rigsby,

I absolutely agree with you about providing consistency, not only with the way the database functions, but also that it behaves the same way the operating system does. Copy and paste is a prime example. I was absolutely dreading putting a button next to a field (or making the field a button) simply so the user could copy it. I've watched them work. They all highlight the text, then right click and select copy. To tell them they have to click a button to do this here, but not over here makes them wonder what I'm smoking! They certainly don't care about relationship access privileges, or gasp! FileMaker limitations! (Not a good line when one is trying to sell something built in FileMaker)

The other problem I knew I would run into with the script was that it would copy the entire field at once. Sometimes they highlight only a portion of it to copy. So really the only "issue" with the calculation solution is inflation of the size of the database. The largest database is 800 megabytes and growing. They don't want to archive records (it a database of library text entries).

[Rigsby]

Inflating the size of a database can be a problem with too many calculating fields, but in this case I don

[Vaughan]

The only problem with duplicated calc fields is that they make imports and exports messier.