Scripting for Unique Value

[ssimons]

:confused: I would like to script the unique value validation rather then using the check box on the options for a field. I have a new screen and I want the first thing that is done when you press the accept button to be a validation that the value entered is unique. Is there a way of doing this? I've searched, but haven't found any instructions for doing something like this. Any help that could be offered would be great.

Sarah

[Raybaudi]

Hi

I think that you haven't found anything about this type of validation because...

it's time wasting !

Do you wish the user enter wrong data and finally discover that ?

Isn't it better to advice him immediately ?

[comment]

Since when does a Chindogu maker complain about wasting time? Anyway, I think it's perfectly sensible to do validation after initial data entry - hate those beeps...

To find out if an entry is unique, you need a relationship, linking the entry field to the validated field. The best way, IMHO, is to make the entire data entry layout with global fields. This way you don't actually add a record to the table until after the data has been validated. The global fields can be in the same table, or in their own table - it doesn't matter much.

[Raybaudi]

The best way, IMHO, is to make the entire data entry layout with global fields. This way you don't actually add a record to the table until after the data has been validated.

So we have to wast time to make the new layout too. :)

[comment]

If you consider building a solid user interface a waste of time, then yes.

[Raybaudi]

No, this isn't correct.

I consider a waste of time making a new layout with global fields, a new relationship and a script only to avoid to make a field autovalidate itself as unique during data entry ( only a check away !)

BTW Chindogu makers make strangeness and unusual things, but who said that they wast their time ?

And when we argued ?

[comment]

Maybe so, but you are not the user. I, for example, don't like it when Filemaker checks me as I enter data. I believe the polite thing to do is to wait until I am done, then say what you have to say.

But that is not the point: deferring validation is just the gravy here. The main purpose is to enable the user to fill out a record, then change his/her mind about the whole thing. In a multi-user scenario, I don't know of any other way to have this kind of a "scratch-pad". Filemaker's method of committing a record just because the user clicked on the background is rather lame (I think I have seen a suggestion to make the entire background a button, just to prevent commiting a record by accidental clicking...).

When committing a new record means a tax payment is due on it, and having "holes" in your serial numbers means a huge fine and possibly a jail sentence - no, I don't think it is a waste of time.

[ssimons]

The problem with the system doing the validation automatically here is I only have one field, an accept button and a cancel button. if the user doesn't tab out of the field and instead presses the accept button there is no way for me, at least not that I've found, to stop my accept script from running if the validation fails because it's based on the field and not the script that is running. I don't feel this is a waste of time, I feel I'm building a solid user interface.

Comment - Thank you very much for your information. I'm going to work on it this morning.

Sarah

Edited January 20, 2006 by Guest

[comment]

Well, you *could* start your script with Commit Records - but it makes for a lousy user experience, as shown in the attached.

Untitled.fp7.zip

[ssimons]

Thanks for the example. What I ended up doing...and please keep in mind I'm fairly new to FMP and have had no training, so whatever works...was when the accept button is pressed I'm taking the value entered into the new field performing a script to run through a find and if it's found displaying a message that it already exists and taking the user back to the new screen, but if if doesn't already exist then commit the record. I know if there are a lot of records the find process could be slow, but with what I'm working on there shouldn't be more then 500 records entered so I should be fine.

Thank you so much for your example and recomendations.

Sarah

[comment]

Speed issues aside, by performing a find you're losing your current found set. That might be aggravating. See the attached for an example using a relationship.

Untitled2.fp7.zip

[ssimons]

Thank you so much. You're example really spelled it out for me. Not only was that easier, but it was a lot less script lines to type.

Here's another question for you..sorry.

Do you know how to remove a carriage return when commiting records? For instance if instead of typing a new record someone cuts and pastes it in and there's a carriage return.

Once again. Thank you so much for your help.

Sarah

[comment]

Assuming you don't want ANY carriage returns in the field, you can set the field to:

TrimAll ( Substitute ( gNewValue ; ¶ ; " " ) ; 0 ; 0 )

I would also add TextFormatRemove() to deal with cut&paste.

[ssimons]

Hopefully, this will be my last question for you, I'm sure you're getting tired of me by now. Would TrimAll also take care of any spaces located in the beginning or end or would I have to do a separate Trim statement for that?

[comment]

TrimAll ( text ; 0 ; 0 ) will remove all leading and trailing spaces in text, and reduce multiple spaces between words to 1 space.

[ssimons]

Great. Thank you so much for all your help.