Duplicate Warning is real time?

[John Chamberlain]

Is it possible to get duplicate warnings is real time? I have a file that checks for duplicated names and for duplicated addresses. The warning fields work, except for one thing - you have to go out of a record, and then come back to it (or do a find on the warning field being greater than 0) to get the warning field to show. It would be so much more convinient if the data entry person could see the warning just as the data is entered.

Any ideas gratefully appreciated.

[LaRetta]

Hi John,

I'm not sure why you must leave the record or search at all. Is it unstored? The field doesn't display a 0 or 1? Why don't you give us your warning calc and how dups are determined?

You can probably use a Case Statement which can display text (in red if you wish) whenever a 'duplicate' field is exited. Is that real time enough? But it depends upon your structure and your warning calc itself.

The warning message will display as soon as the User leaves the Name field. Same with the address field.

LaRetta

[John Chamberlain]

Hi LaRetta

I defined these two fields

Dupcheck Address:

Case(IsEmpty(Dup Checkoff Address), Left(Address Line,14) & ZIP Code)

DupWarning Address:

If(Count(Dup Address::DupCheck Address)>1, "WARNING!!! This address may be a duplicate!!!", "")

And a self relationship:

Dup Address:

Dupcheck Address::Dupcheck Address

In the first field the "Dup Checkoff Address is to allow for addresses that exceed 14 characters, yet may still need to be separate records (e.g. 12345 So, Los Angeles St. Apt. A vs 12345 So, Los Angeles St. Apt.

I should mention that I have created these things for other files, and they worked in real time for awhile but then started to behave the same as this one. That is to say, they now require exiting the record and coming back for the warning to display.

Regards,

[-Queue-]

Well, for one thing, Count(dup add::dup check add) isn't going to be greater than one until you exit the duplicate record and the changes are 'committed'. Secondly, what if someone adds an extra space between words/letters or abbreviates one and doesn't abbreviate another? You will have 'dupes' but no way to tag them. What I'm getting at is that using an address as a key field is not a good idea and is prone to failure.

[John Chamberlain]

Yes, you are right about the abbreviations, etc. However I did give the data entry person (and ther is only one) a set of standards on abbreviations, and this is the only way I can get even a clue as whether or not an address might be a duplicate. Also, the record contains two names (one male & the other female) and I have similar checks on them.

Bottom line is I can't get it to display until I exit and then re-enter the record. Am I correct?

[-Queue-]

Exit, yes. Re-enter, unnecessary. Once the record has been clicked out of or 'Enter' is pressed on the numeric keypad, the changes are committed and will then update any calculations. Entering the record again does nothing except lock it from other users.

[LaRetta]

Hi John,

Well, I agree with Queue ... it might be better to use a phone number but for another reason ... there will be less chance of having indexing problems due to your Address field (combined with name field) being more than 20 per word (or 60 per key). You might create a calc (number, unstored) with: Length(YourKeyField) just to see how many characters they're running.

And now that makes sense why your warning flag wasn't appearing. Your warning flag will not appear until you Exit Record/Request and there is no way (that I know of), to force an Exit Record upon field exit except for using a plug-in. And as Queue pointed out

[John Chamberlain]

OK! First, to Queue, thanks so much - I will put the requirement to use "Enter" into the data entry instructions right away - it works for the purpose I have in mind.

LaRetta - you are really a big help on this (and on others you have responded to). I'm sure that your ideas will eventually make this foolproof. In the meantime, I don't know about Scriptit - what is it, and where do I find it?

Regards, and thanks so much for helping an old guy figure out some basics.

[LaRetta]

Hi John,

ScriptIt can be found at:

CNS Plug-In ScriptIt

What it can do (I've been told) is allow script to activate on field exit. But I'm sure there are other plug-ins available which will do the same thing. I don't use plug-ins because, so far, I've been able to accomplish everything using FM's native functions. You might look into Troi also. They have some wonderful plug-ins (from what everyone says).

The last option I suggested will do the same thing as the plug-in, ie, notify the User of the error as soon as they leave the field. And it doesn't require that the User hit [Enter] on the numeric keypad or watch for a warning flag to display. And it costs nothing.

If the issue of duplicates is very important, I wouldn't leave it in the hands of any data-entry person (even one highly competent). That's why I suggested Field Validation. It will happen immediately and it will prevent a User from continuing until they correct it.

Cheers,

LaRetta

[-Queue-]

The only problem with using field validation is that if you have buttons on the same screen as your data entry and a user clicks one before exiting the record, your scripts can fail miserably if any of the data is invalid, because you can't change Modes, etc. if your validations fail. Therefore, data to be entered in Find Mode can be entered in Browse Mode instead, overwriting valid data undesirably. But there is a decent workaround for this. Put this series of steps at the beginning of all accessible button scripts and you'll save yourself much possible heartache:

Set Error Capture [On]

Go to Field[]

If [status(CurrentError)]

Show Message ["You have entered invalid information. Please change it."]

Halt Script

End If

[Anatoli]

Web warning:

You may have to design heavy workaround for web access, if you use FM validation. Because of Web validation problems I almost stop using FM field validations.

[LaRetta]

Hi Queue,

Thanks for pointing that out. Those lines should be in just about every script, I would think! I think I would also add Exit Record/Request right before the If(Status(CurrentError).

Hi Anatoli!!

Thanks for the web warning. I didn't know that.

Cheers!

LaRetta

[-Queue-]

The Go to Field[] serves the same purpose as Exit Record/Request, and, from what I've heard, is more reliable in refreshing the screen.

[LaRetta]

Sorry Queue, I didn't even see that there! Time for a vacation, I guess.

LaRetta

[Anatoli]

LaRetta,

on web the whole story is different, because it is not permissible to get ANY dialog box EVER! It will halt the WebServer.

The workaround is first prepare the condition for validation to be the valid one, then let user submit his/hers entry, compare/validate that in e.g. Lasso with Lasso Script and if it is everything OK, post user response to the FileMaker. Then remove the temporary validation from FM. It is not exactly real time but it is the only thing, which will not stop FM in further executing.

That was requirement from boss of my last major work.

I would not use the built-in FM validation, but 2 validations -- FM script for FM network and Lasso validation for web users.