Perform FIND not working.

[ron G]

Yes, I know I've asked this question before. And yes, I got it working before.

But, with this 'little' script, FM refuses to find all members of a field that are empty.

There is a Members table.

There is Members:Type which holds the membership type: 'Yearly', 'Honorary' etc.

There is a field called Mem_Can which holds either 'Member' or 'Candidate'

This is the script:

Specifically, this is the FIND:

And, this is the error:

I just want to find all the 'Members' who have a blank Members:Type. (There are 48 records that meet the criteria)

What am I missing?

Thanks

[VincentO'B]

Hi Ron

Try:

Go to my table

Enter find mode

Set 'my field' "*"

Perform find

Show omitted.

that should find all records with no value in 'My field'

You do not need the show all records script step to perform a find and it would be quicker to do the sort after the find as you will be acting on a smaller set of records.

Regards.

Vincent

[ron G]

Hey Vincent,

Isn't there a way to use script commands (Perform Find) and (Constrain) to affect this same outcome WITHOUT bringing up a table on a layout and using setfield to input the values into the right fields? If not, do you know why FM provides these commands?

Thanks for your thoughts. I am still perplexed around when to use Perform Find (script command) and when to use the Set Field method.

Perplexed..

Ron

[bruceR]

You mean, isn't there a confusing way to perform a find that doesn't let you know what you're doing and doesn't let anybody else help troubleshoot the problem?

Why yes; keep doing what you're doing.

Why the resistance to Enter find mode; set field; perform find? It's bulletproof and easy to debug.

[VincentO'B]

Ron

There are likely many ways of achieving the same result and you could well be able to do it as you describe, my suggestion may not be the best but I can not think of a more direct way it imitates how you would do it manually, you can also pause the script temporarily after 'perform find' to check that you get the required result.

You do not have to see the table if you add the 'freeze window' script step and add a script step at the end to return you to where you started, it happens in the background.

You could also use a calculation field and the 'Count' or Get 'FoundCount' functions if you just want to count how many records fit this query, I am not sure whether you want to find the records or just count them.

You are not alone, after many years of developing with FM many things still perplex me it's what stops me getting bored.

Best Regards

Vincent

[LaRetta]

... to affect this same outcome WITHOUT bringing up a table on a layout and using setfield to input the values into the right fields?

Hi Ron,

You don't need to go to the other table if the tables are related - you can search from where you are at. However, the outcome will be a list of records from the table you are in which have records matching your search in its related table.

I am still perplexed around when to use Perform Find (script command) and when to use the Set Field method.

Nothing at all wrong with that question ... you can use either except in one instance (that I can think of): You cannot enter a calculation or globals into a Perform Find[restore] - it must be literal text or variable. Some Developers only use Set Field[] because, as Bruce says, it displays what is going on in the search criteria whereas (because of poor programming by FM), the 'restore' part of Enter Find Mode[] and Perform Find[] do not display and we must open them to see their contents.

I just want to find all the 'Members' who have a blank Members:Type.

Enter Find Mode [ uncheck pause]

Set Field [ Members::Type ; "=" ]

Perform Find[]

An equal sign alone, entered in find mode, finds empty fields. :^)

Edited March 25, 2012 by LaRetta

[Lee Smith]

Ron,

This seems to be related to your other post.

Lee

[LaRetta]

I just got dizzy ... reading another post and thinking I had read it before.

Ron, please do not double post. It doubles the work required for us to assist someone. Thank you. And I answered on the other one.

EDITED: oOops, no I answered on this one. :drool:

Edited March 25, 2012 by LaRetta

[ron G]

Hi Ron,

You don't need to go to the other table if the tables are related - you can search from where you are at. However, the outcome will be a list of records from the table you are in which have records matching your search in its related table.

Nothing at all wrong with that question ... you can use either except in one instance (that I can think of): You cannot enter a calculation or globals into a Perform Find[restore] - it must be literal text or variable. Some Developers only use Set Field[] because, as Bruce says, it displays what is going on in the search criteria whereas (because of poor programming by FM), the 'restore' part of Enter Find Mode[] and Perform Find[] do not display and we must open them to see their contents.

Enter Find Mode [ uncheck pause]

Set Field [ Members::Type ; "=" ]

Perform Find[]

An equal sign alone, entered in find mode, finds empty fields. :^)

Ooops on the double posting. I tend to get wiggy after I get into the mid a.m. hours...

As for the Perform Find... I am in the table I want to 'find'..... Members.

The Members::Mem_Can field can have either "Member" or "Candidate" as a value. I want 'Member'.

Of the Members selected, I want to constrain the sub set to include only the ones who have a TYPE = (ie, blank)

Shouldn't this work as just a couple of script commands? (ie, without jumping to the layout, using setfield etc...)

Thanks

Ron

[bcooney]

You really don't need to constrain. Just enter both criteria when you find (set two fields): Member; "Member" and MemType = "="

PS: I've pointed out to you before that I would use IDs and not text values. Also, do you have Membership records? Isn't a person a member if they have an active membership record?

[LaRetta]

Your script is all wrong ... you are using Set Field[] before you even enter Find Mode. And what is stored in your Perform Find?

If you want to use Perform Find[] then just enter them both as criteria in the Perform Find[] ... on two separate lines (you are wanting an AND condition). Searching for empty Type would mean just typing an equal in the 'Specify Find REquest' box.

So do one or the other ... either use Perform Find [ Restore ] which holds both fields you are searching ... or use script as:

Enter Find Mode [ uncheck pause]

Set Field [ Members::Mem_Can = "Member"

Set Field [ Members::Type ; "=" ]

Perform Find[]

Be sure to error trap. BUT ... I just re-read it all ... isn't that global field gMem/can? As I said, globals can't be in stored Perform Find[]s so you must use the full script if you are using a global to hold the User choice.

Edited March 26, 2012 by LaRetta

[LaRetta]

I've pointed out to you before that I would use IDs and not text values.

Hi Barbara,

What are you suggesting here? That Members::Mem_Can = "Member" should instead be searching for an ID and the word Member should not exist as text? There is nothing wrong with using text values ... I know you get firm on this but I do not agree that IDs should be used in all cases. Whether they should be used in this case, I could not say. But having a field with the value 'Member' wouldn't necessarily violate good design.

If there are two types of Members = Member or Guest, another table does not need to be created to hold the values and use their IDs. That is carrying principle just too far (even to me). And nowhere do I see we are talking about keys either.

[bcooney]

I suppose I'm nudging Ron a bit. What is a member as opposed to a candidate? Is he thinking memberships at all? Perhaps suggestions such as mine will reveal that his system has room to grow.

I stand by my insistence on IDs.

[Lee Smith]

Ooops on the double posting. I tend to get wiggy after I get into the mid a.m. hours...

So are we suppose to use our development time to try and figure things out for you?

I suppose I'm nudging Ron a bit.

I don't think it is working

Lee

[LaRetta]

I always like the nudging - towards me, towards others, by others. Any time we can help each other consider things they hadn't thought of, it is to their (and others') benefit (and even to our own).

I stand by my insistence on IDs.

Now see? This is where we part simply because your stance leaves no room for simple text fields such as this one - there are only two values - Member or Candidate. People reading this would think that you insist on creating a table with IDs to hold two records - Member and Candidate and you can't be suggesting that, can you?

I strongly believe in IDs when needed (you know me also) but they are not needed in all cases, like this one. I even use some custom value lists (OMG)! I believe in planning for contingency and growth but I have also seen solutions with 45 tables of value list data which had to be included in migrations, LOL, when many of them were just two to four records and their word meanings wouldn't have (probably) ever changed.

It is simpler to replace field contents through the records if it comes to actually changing one of these principle identifiers than the added graph clutter, being required to then use pop-up to display the real text name (and turn off entry) or be required to relate the value list so you can place the related 'text' value onto a layout (or create calculations of the text or merge variables or) ... and why? Because you want a simple word.

Nope, we will just have to agree to disagree (on this one) then because there simply must be room for common sense decisions of allowing words to just mean what the word means. :yes:

[adyf]

Some Developers only use Set Field[] because, as Bruce says, it displays what is going on in the search criteria whereas (because of poor programming by FM), the 'restore' part of Enter Find Mode[] and Perform Find[] do not display and we must open them to see their contents.

Enter Find Mode [ uncheck pause]

Set Field [ Members::Type ; "=" ]

Perform Find[]

An equal sign alone, entered in find mode, finds empty fields. :^)

Hi LaRetta, so using the Set Field() function is definitely the way to go as part of a find script? I have countless find scripts using Perform Find 'restore', Constrain 'restore' etc.

[LaRetta]

Some developers find using Set Field[] easier to work with because the find criteria is clearly displayed just when viewing the script. It is exactly the issue we were struggling with ... a Perform Find [ Restore ] doesn't show the criteria. So from that aspect, it is more difficult when developing.

However, I use Perform Find [ ] many times sometimes because it is more concise and produces less script clutter so depending upon the types of End/Ifs and Loops, I might take a shortcut and use Perform Find[Restore] on something simple that I probably won't need to change, particularly if I've commented what is happening with a group process. And yes, I use separators and heavily comment my scripts.

It is too bad that FM doesn't provide the criteria when viewing the script ... there is plenty of room on its line. I put in the request several years ago but they must have other things on their list ... either that or they didn't get my email. If they would have gotten my email, surely they would have changed it immediately ...

So I use Restored finds only when very simple OR ... as Lee suggests, sometimes (particularly if new to scripting) it is easier to perform your find manually. Then when you create your first Perform Find script step and open the find request, it is all there - just click the 'specify find request' to store it with the script step.

OH ... and the other thing I don't like about stored find requests is that you cannot change the order of multiple find requests (within a single request) and sometimes changing the order is necessary. So only use stored finds if you are newer to scripting and want to run the find first or if the request is very simple. :^)

Edited March 26, 2012 by LaRetta

[comment]

there are only two values - Member or Candidate. People reading this would think that you insist on creating a table with IDs to hold two records - Member and Candidate and you can't be suggesting that, can you?

Asked and answered:

http://fmforums.com/forum/topic/80943-one-to-many-to-many/page__st__20__p__376463#entry376463

:shocked:

[Lee Smith]

So I use Restored finds only when very simple OR ... as Lee suggests,

ROTFLMAO

In the duplicate post. :giggle2:

[LaRetta]

:jester: Funny Lee!

Oh, ahm, well, I somehow missed that intriguing thread, Michael. I am a firm believer in setting rules (heck, I make up 20 rules a day for myself, lol) and I can tend to speak in absolutes sometimes and Barbara and I usually agree on most things so when we don't it is usually a definition issue - that's why I asked.

But no. I wouldn't create a table for two values at the high level of the food chain (the top three of structure) nor would I create them on some of the other examples referenced in that thread, but that's okay too. Every person reading the forum chooses how to use the information we, as a group, provide. It is the mix of all of us as ingredients (some are carrots and some are potatoes and Comment is the meat, lol) which make the best stew.

So let's keep cooking!! :laugh2:

[bcooney]

"Intriguing thread," LaRetta? I was barely holding my own. But, I stood my ground and honestly feel that hard-coded value lists are very rarely needed. I don't do separation model either, so rely on import/export and hc value lists don't, as you know.

As far as Ron's system, well I suppose it pushes buttons for me. One system I've worked on for about the last 5 yrs is a membership system. So, I feel that his model is simplistic, but perhaps it's all he needs.

[LaRetta]

Yes, the thread was intriguing to me, Barbara, how differently folks can see the same issue even when presented with logic. This business intrigues me and so does how folks communicate using written word and I am sorry if using that word didn't sit well with you. Maybe I should have said fascinating instead. :^)

I do not feel the point is holding one's own or standing one's ground ... that implies someone is feeling attacked and I did not see nor feel anyone was being attacked, either in this thread or the other one. I DID see that I have a different perspective ... I shared mine.

[bcooney]

Oh my, I didn't mean to imply I was being attacked, but certainly challenged. And it's good. It helps one to break out of ruts and think different, lol. Always good to hear a different perspective.

[LaRetta]

Oh good! I know Michael can get a bit ... uhm ... specific. I like it when he does and even if it is directed towards me (usually anyway, LOL). I'm glad you realize we are discussing and disagreeing on just one perspective and most times we agree ... well, at least you and I do.

I'm just teasin' with ya, Michael.

[bcooney]

Yes, uhm..specific. Not one for the use of the word "always" and certainly calls me out on my all-too-quick, "nevers." Keeps you on your toes, that guy (or is he really an 80yr old grandmother...?)

[LaRetta]

Aggrhhhhhh!!! If he is an 80-year-old grandmother then I want whatever he's eating!

Ah yes, the importance of being concise and accurate ... we'd normally have to pay someone to help us fine-tune. That was one thing I loved about JT also (and still do) ... how he would always respond by providing a better calculation or faster script so everyone gets the benefit of the best we can gather amongst us.