Editing Value Lists - Custom Values

[Peter Guthrie]

This question addresses a larger issue, so let me start with that larger issue. I have made an FM database template that many of my colleagues use for specific events. Each event is different, so the users start with a clean version of the template for each event. Of course, the easiest way to do this is to provide a Cloned copy of the template. However, I would like to be able to add a User Preference feature that each user could set for their specific convenience. Unfortunately, I know of no way to preserve any "preferences" (values) in a Cloned database.

One solution would be to be able to edit the Custom Values used to generate a Value List. I know one can create a Value List from a field, and thereby generate an "editable" Value List, but the values in taht field disappear when the records are deleted making the Clone. I've tried looking for anything else that would be preserved in a clone (even so far as setting the View As for a Layout and reading the LayoutViewStatus to create a binary storage bit - unfortunately, the layout view doesn't seem to be faithfully preserved when you close the database, so that works while the database is open (as do global variables), but doesn't help with the overall problem.

So: Two questions:

1) Anyone have any ideas about how to preserve some limited data in a Cloned file?

2) Anyone know if one can edit the Custom Values in a Value List

I'd rather avoid plug-in's - Federal Government computers = security obsessed, and relatively naive users.

Thanks,

pbg

p.s. if this more general question would be better posted elsewhere in the forum, please feel free to tell me to go there :-)

[comment]

Well, the very idea behind cloning a file is to get rid of all data. If you want some of the old data, you'll need to import it. This could be scripted - provided you know in advance the name and path of the original.

However, one cannot help wondering why they need a separate file for each event.

[Fitch]

Michael has identified the "larger issue."

But back to your question. Keep the prefs in a separate table. Then, rather than clone the file, delete all records in the non-prefs table(s), and save a compressed copy.

There is a checkbox next to where you assign the value list: "Allow editing of value list." Is that not what you had in mind?

[Peter Guthrie]

Well, the very idea behind cloning a file is to get rid of all data. If you want some of the old data, you'll need to import it. This could be scripted - provided you know in advance the name and path of the original.

However, one cannot help wondering why they need a separate file for each event.

Yes, cloning is to get rid of data, but I'm thinking of user preferences as something beyond "normal data". (e.g. having a global variable that survived file closure would do the same thing for me: $$$variable?)

As to why they need a separate file for each event - the information in the database must be purged after the event (confidential information), so they essentially start with a clean database each time, and cloning is one way to do this. Finally, I thought about an import, but don't trust the users to keep track of the exported preferences file, and am trying to allow for individual flexibility, so I don't want to dictate a need for multiple files.

This is not an essential need - just a desire to create the "perfect tool" (OCD kicking in :-, and was just wondering if anyone had solved a similar problem.

Thanks for the comments

CUT - There is a checkbox next to where you assign the value list: "Allow editing of value list." Is that not what you had in mind?

Yes, but that allows the user to edit the value list. I want to be able to edit the value list from inside a script - read and write to the list based on row #

pbg

[comment]

the information in the database must be purged after the event (confidential information)

So why not simply delete the data pertaining to that event - and keep working with the same file on other events?

You could also use a separate file for the permanent data - but I believe as a user I would prefer to be exempted from going through the process of creating a fresh clone every time.