Trying to capture "pre-edit" data with Zippscript

[djlane]

I’m trying to use Zippscript to manage changes made to data within a field.

I have a Parent Table with several child tables. I don’t want the user to be able to change the text (ie the Name) in the Parent table if there are active child records, but to allow the change if there are no child records.

I use Zippscript to capture that a change has been made to my text field, and invoke a script to check for the presence or otherwise of related child records.

I have found that zippscript loses sight of the current record if the user exits the field using a mouse click to a different record. But, by having ZippScript capture the RecordID, I can go back to the correct record. So far so good.

But I cannnot seem to get the field to revert to its original value. Revert Record does not do it (but strangely it does sometimes…). And Zippscript captures the changed value of the field, not the original ("Pre-Edit") value that I want to restore to. How do I capture the original value so I can revert it, or how do I return the field to its original value?

The script is attached.

The system is for tracking business records, like Folders, Tapes, and Containers. Tables Hierarchy 1, 2 and 3 are tables where you set up the hierarchy of the company. Eg, 1 = Divisions > 2 = Business Units > 3 = Departments, or 1 = Company > 2 = Branch > 3 = Sub Branch. The Related (“child”) Records are in the Folder, Tape, and Container tables.

Zippscript_problem.zip

[comment]

Why do you need this at all? It sounds like you are using the name as a matchfield for relationship/s, instead of a serial ID.

Anyway, if you must, then how about something simple?

DetectChildren.fp7.zip

[djlane]

Hi Comment,

No I'm not using the name as a match field (I am using a serialID), and I also have no problem detecting the presence of child records. Thats not the issue.

I don't want someone renaming a division from "Marketing" to "Operations" if Marketing has related records. Yes, the serialID remains the same, but now all the departments in Marketing will look like they are part of Operations.

My issue is how to capture the former value of a field that has been changed, so that I can restore it if necessary to its original value.

[Søren Dyhr]

This might be an option:

http://www.databasepros.com/FMPro?-DB=resources.fp5&-lay=cgi&-format=list.html&-FIND=+&resource_id=DBPros000761

Where existence of child records pushes the padlock button!

--sd

[LaRetta]

Maybe I'm missing something. Comment's file appears to do exactly what is requested!? It stops modification once child records are present. Theory of application would be the same, no? It simply removes the problem before it can happen so there is no need to capture the prior value.

UPDATE: This is prime example where solving problem before it happens; eliminating the need for plug-in horse play. Good Lord, that sounded like Soren.

Edited January 25, 2008 by Guest

[Søren Dyhr]

One problem though is that you can't copy/paste values from Comment's suggestion, which might be one of many secretly kept issues?

The dymo-king have been in action again an attached a lot of the wrong labels to the problem solely on the assumption that scripting really is required. May we ask what tools realm you are thinking filemaker into - to explain the event trigger urge?

--sd

[comment]

I still don't get it myself.

I don't want someone renaming a division from "Marketing" to "Operations" if Marketing has related records.

Why not? I would think renaming a division is a legitimate user action at any time. Perhaps it needs to be restricted to authorized users only, but that would be a matter of account privileges. What has the existence of related records to do with this?

But what really puzzles me is that you DO allow them to change it - or better put, you allow them to THINK they're changing it. Then, after they have spent time and effort changing it, you want to roll it back. As a user I would find that very frustrating.

[Søren Dyhr]

I keep thinking we're asked in vain here, the issues raised here has absolutely nothing or hardly anything to do with the problems, they're euphemisms!

My guess is that we're dealing "saying" numbering, serving both relational link as well as being a human-readable, and the need to issue pro-forma invoices as part of a scam.

So the real problem is an organization thing, bad management ... or getting the wrong kind of employees to do tasks.

--sd

[comment]

Maybe, and maybe not. What's the point in guessing?

[djlane]

Ok, let me explain a bit more.

The system is to store details of corporate records which will be kept in an offsite records management facility. The system will be owned by the records management company, and they will give the software to their clients to allow the clients to index their records. So when a client needs to retrieve a certain document, they can look in the system, find the caton barcode number of the box or folder that it's is, and then tell the recoreds management company which box to deliver to the client.

So the system allows the client to set up his company hierarchy in whatever way he wants (up to three levels).$ So, for example a client might setup his hierrachy as Divisions, then Departments, then Branches. So he sets up his divisions names first, then he sets up his Departments, then his Branches. Each Branch belongs to a certain Department which belongs to a certain Division.

Then he starts indexing his files. Each filefolder has details about the contents of the folder, and also which Branch/department/division it is from.

Three months later, some user decides to rename one of the divisions from Marketing to Operations.

Now the Marketing division does not exist anymore, but all the departments and branches below it are part of the operations division.

This could be intentional or it might very well not be. And its less of an issue if there are no related records. ie if there are no filefolders or cartons which have been indexed with the Division name of Marketing.

However, Comment seems to have made a very simple suggestion – to manage it with privileges. Nice and simple. Only a certain privilege set gets to modify the hierarchy setup. Soren says the same thing – get the right employees to do the job.

And Comments ridiculously simple script allows me to capture the value of the field before it was edited. He did in 5 lines what I could not achieve in 25. I didn’t know you could do that - place a button over a field to activate a script, then have the script bring you to the field below the button. Very nice !

Thanks !

[Søren Dyhr]

But hierarchies are usually obvious candidates for a recursive one-2-many structure:

http://jonathanstark.com/recursive_data_structures.php

--sd

[Søren Dyhr]

Maybe, and maybe not. What's the point in guessing?

By guessing just a tad wrong deliberately, will you always make the OP aware of the insufficiencies supplied!

By minimizing some aspect and exaggerating others, does it convey...

--sd

[comment]

Just to emphasize: the script is merely a UI device, designed to avoid Filemaker's annoying validation dialog. It needs to be implemented IN ADDITION to the real security measures in Accounts & Privileges and/or field validation.

I still don't get the renaming issue: if a document belongs to BranchID 105 of DepartmentID 23 of DivisionID 1 - what difference does it make if any of these are renamed? Actually, the document should belong ONLY to BranchID 105 (105 being a unique structural ID) - so that if the branch is reassigned to another department, its documents remain related to it by its unique ID. They remain related even if a branch is promoted to a department.

In fact, I don't see why the storage company needs to even care about their clients' corporate hierarchy - all that's needed is for each corporate unit to have a unique ID, be it the company headquarters or the Alaska branch.

If the physical boxes are related to their owner in the same way as records in a database, then the owner's name and it's position in the company's hierarchy become irrelevant to the retrieving process. Otherwise, you are saying that signing up to this service requires the clients to freeze their corporate structure forever.

[djlane]

Is not that the storage company cares about the corporate hierarchy - you are correct in saying that they only care about the box number.

My concern is that of a user searching for a document. Users will not generally search for a document by its unique ID number. They will search by something like document type from a certain department in a certain date range. If a Department has been renamed, then a person searching for a document from that department will have to search using the departments former name.

I agree with you that freezing the corporate structure forever is also not a good idea, but how else to manage the issue of searching for documents belonging to a department that no longer exists?

[comment]

I can't really answer that without knowing much more about how it's supposed to work (who decides what's in a box, how are the documents described, and a lot more). Perhaps all you need is an audit-log type field to shadow the UnitName field (auto-enter itself & UnitName & ¶). Then direct the search/relationship to use this shadow field instead of UnitName.

[djlane]

OK. Or even just a plain text narrative field that allows someone to make a note that a certain unit has been renamed.