WC Attribute Search not showing all results when using wildcard?!?

[LawrenceS]

We have an interesting case where we perform 2 different attribute searches looking for CAD objects but the wildcard search shows less results than the non-wildcard search!

For example if we search by our ECN attribute:

ECN Attribute Search	Number results	Type  of results
0046945	2	asm and dwg
*46945	1	asm only
*46945*	2	asm and dwg
46945*	0	none, as expected

Notes about the above tests:

• 0046945 is an exact search of the entire attribute field
• All results were performed by adding/removing text instead of copying and pasting the above.
• System is set to Simple Search and NOT Advanced (Although I think that is only applicable to the index search)

Things I tried:

• My first guess was that there was an empty space somewhere in the file name but the above search results exclude that possibility (viz. the exact text 0046945 works. However I did export to notepad++ as csv to look at the raw text and saw no extra characters in that field that differed between the dwg and asm. 
• The search view is also identical, so it doesn't appear to be filtering out a file type. 
• I also could not find anything related in the search user preferences.

My questions

1. Does anyone know why searching with a star at the beginning of an attribute requires a star at the end to get all the results, even though there is no difference in the attribute text saved with the cad files?  Also why the asm comes up but not the .drw?
2. Do you know how to fix this?

Thanks, Lawrence

[BenLoosli]

What does the detail information page show for that object in Windchill?

[LawrenceS]

Yes, detail pages show the identical attribute value

• asm
  • 
• .drw
  • 

This is very bizarre. 

[LawrenceS]

And here are screenshots of the 2 searches:

• Complete attribute (no wildcard stars):
  • 
• Partial attribute with wildcard star replacing missing text:
  • 

Again, between these 2 searches all I did was delete the 2 zeros and replace with a star, then made sure both searches used the same view (latest in this case...although I tried various views to make sure no filter buried inside one of the view's criteria themselves).

[lhoogeveen]

Maybe try removing the Revision and Iteration from the search? Those fields are very poorly handled by Windchill search and can lead to weird search results:

• Related Product Idea: Enable Windchill search to support ‘pure’ latest iteration search when additional criteria is applied.
• Related Windchill Help Documentation
• CS58285
• CS157314

[LawrenceS]

Thanks for the tip.  It looks like in this case it was tied to WC not showing if there is a trailing space...even when there is one.

[rleir · Accepted solution]

Hi Lawrence,

1/ with no asterisks, there is an implied trailing asterisk

2/ with a leading asterisk, there is no implied trailing asterisk

3/ both asterisks supplied

4/ the leading 00 is needed, as understood

The rules on implied asterisks are documented by PTC but I don't have a link handy for you.

The results you are seeing suggest that the DWG object's attribute has a trailing space or tab, but that is just a guess.

HTH -- Rick

[LawrenceS]

@rleir, Well it looks like you are right and provided some very helpful supporting information for understanding what WC is doing!  I will add this to my table in the question body.  Thank you!

After your post I decided to open both model and dwg in Creo, and sure enough I found that the dwg had a trailing space!

It is very surprising that WC removes the trailing space from the attribute filed so that when I checked in the following ways it shows NO trailing space:

• Search results:
  • Highlighted the entire field
  • Exported the search results to .csv or .txt
• Detail page:
  • Highlighted the entire attribute filed text does not show a trailing zero

It is interesting that PTC chose to not display trailing spaces in WC, while still restricting the search.  I always liked the simplicity and consistency of attribute searches, but this seems a step backwards.

@rleir , do you or anyone else know of a WC option that can turn on/off or modify this behavior?

[LawrenceS]

Well, It looks like I cannot edit my own post/question so will add the table with @rleir very helpful post.

ECN Attribute Search	Number results	Type  of results	Explanation
0046945	2	asm and dwg	with no asterisks, there is an implied trailing asterisk
*46945	1	asm only	with a leading asterisk, there is no implied trailing asterisk
*46945*	2	asm and dwg	both asterisks supplied
46945*	0	none, as expected	the leading 00 is needed, as understood

[BjoernRueegg]

@LawrenceS Could you please explain why the asm is being shown with *46945 "with a leading asterisk, there is no implied trailing asterisk"? I just don't understand it. The drawing needs to be shown also, or am I wrong?

[rleir]

Hi Bruegg,

See my post from Mar 30, it will help explain that.

Hi Lawrence, 

thanks for exposing some 'interesting' Windchill behaviour.

cheers -- Rick

[LawrenceS]

@BjoernRueegg did the post rleir help answer your question?

[BjoernRueegg]

@LawrenceS I wish I could say yes, but I don't understand it. Could you please explain it in other words?

[LawrenceS]

---

@BjoernRueegg wrote:
"@lscheeler Could you please explain why the asm is being shown with *46945 "with a leading asterisk, there is no implied trailing asterisk"? I just don't understand it. The drawing needs to be shown also, or am I wrong?"
...

@LawrenceS I wish I could say yes, but I don't understand it. Could you please explain it in other words?

---

I cannot help you understand why PTC did this but what this means is that if you don't use any stars in your attribute search, then

• Windchill (WC) will assume a start at the end of your search criteria
• So it is actually NOT searching for an EXACT match and nothing more
• It is actually search for an exact match with a wildcard at the end
• So having a wildcard anywhere in search criteria will turn off WC from assuming a wildcard at the end.

Since this is pretty confusing considering the following:

• "*" represent the wildcard that WC uses
• For this discussion only, let "%" represent the wildcard that WC uses but hides.
• Then:

Actual ECN Attribute Search	Equivalent Implied ECN Attribute Search (using "%")	Number of Result	What actual ECN attribute values were	Explanation
0046945	0046945%	2	asm: "0046945" dwg: "0046945 "	with no asterisks, there is an implied trailing asterisk
*46945	*46945	1	asm: "0046945" dwg: "0046945 "	with a leading asterisk, there is no implied trailing asterisk
*46945*	*46945*	2	asm: "0046945" dwg: "0046945 "	both asterisks supplied
46945*	46945*	0	asm: "0046945" dwg: "0046945 "	the leading 00 is needed, as understood

(😥 tables are terrible on this form as I can't hardly adjust anything!)

This is based on the rules that @rleir stated and I verified with my situation, however, I have not tested if this applies to all text or just spaces...or what happens if the space is prior to the text instead of trailing.  Perhaps someone else has tested this...?

I hope this is clearer and helps! 😀

[rleir]

Hi all,

If someone can find a reference in the Windchill docs, that would help this discussion.

To sum it up, "there is an implied trailing asterisk when you have not used asterisks at the start".

If you search for 00469 then Windchill searches for 00469* and finds things.

If you search for *469* then Windchill searches for *469* and finds things.  BUT

if you search for 469 then Windchill searches for 469* without the leading zero's, and does not find what you want.

Did I just muddy the waters?

HTH -- Rick

[LawrenceS]

@rleir @BjoernRueegg @STEVEG 

We tested another search and we found that the assumed/implied wildcard at the end is only a PARTIAL wildcard!  So for example, if we search

• "0046945" it will find "0046945 "
• "004694" will NOT find "0046945" nor "0046945 "
• I have not tested how WC works if spaces are anywhere else in the attribute (e.g. " 0046945" or "004694 5").
• We see this using WC11.0 M030
• This is where PTC documentation would be very helpful if anyone has any links! 😀 Here are some that I found:
  • This article says that WC does NOT use implied asterisks for 'forms' searches (think that is attribute search):
    • https://www.ptc.com/en/support/article/CS304749? &language=en&posno=1&q=implied%20wildcards&source=search
  • Although I don't completely understand this help page, it may explain this behavior if it considers trailing (and maybe leading) spaces as a substring and indexes it differently (though as I understand it attribute searches aren't supposed to be indexed searches).
    • http://support.ptc.com/help/windchill/wnc/r11.1_m020/whc_en/index.html#page/Windchill_Help_Center%2FSubstringIndexAbout.html%23
  • I haven't found any other PTC articles that explicitly explain our observed behavior though...maybe one of you can/have?

So these are the updated attribute search rules from my previous post based on my current testing/knowledge:

• Windchill (WC) will assume a PARTIAL wildcard at the end of your search criteria, but may ONLY apply to spaces
• So attribute Searches are actually NOT searching for an EXACT match and nothing more
• They are actually searching for an exact match with a PARTIAL wildcard at the end
• So having a wildcard anywhere in search criteria will turn off WC from assuming a partial wildcard at the end.
• Since this is pretty confusing considering the following:
  • "*" represent the wildcard that WC uses
  • For this discussion only, let "%" represent the wildcard that WC uses but hides.
    • So far this implied trailing wildcard works for trailing spaces but not for all/most characters.
  • Then:

Actual ECN Attribute Search	Equivalent Implied ECN Attribute Search (using "%")	Number of Result	What actual ECN attribute values were	Explanation
0046945	0046945%	2	asm: "0046945" dwg: "0046945 "	with no asterisks, there is an implied trailing asterisk
*46945	*46945	1	asm: "0046945" dwg: "0046945 "	with a leading asterisk, there is no implied trailing asterisk
*46945*	*46945*	2	asm: "0046945" dwg: "0046945 "	both asterisks supplied
46945*	46945*	0	asm: "0046945" dwg: "0046945 "	the leading 00 is needed, as understood
004694 (This row is new from my previous post)	%	0	asm: "0046945" dwg: "0046945 "	Apparently the implied trailing wildcard (which I'm representing as "%") doesn't work for everything but does for trailing spaces.

[STEVEG]

PTC,  WHYYYYYYYYYYYYYYYYYY?

This all sounds like:

Searching one way works sometimes, but not for others.  Then it works another way in other searches unless you want to do a search on Mondays and Thursdays.  Yikes!

Why can't I just type in a sequence of characters, use an asterisk as a wildcard anywhere in the sequence and as many as I want (just like most other programs in the world), and get a simple search result?

[HJ1]

I was going through the Help Center to understand why Advanced Search gives the results it gives.

Imagine trying to get average users excited about using Windchill, those Active Daily Users who occasionally need a drawing or the docs for a specific product. Tell them to use Advanced Search? I was hoping to.

[rleir]

We are planning to put TWX Navigate in front of Windchill. The search is simpler though less powerful. This will be better for many users.

Another thought: has Windchill search changed with revisions? My experience reported above is with 11.0. Perhaps 11.1 or 11.2 has improved? Today we will learn about 12.0.

cheers -- Rick

[LawrenceS]

Are you doing an Out of the Box ThingWorX Search solution?  if so can you reference documentation or a company app?

Or is it custom just for your guys?

[rleir]

@LawrenceS  TWX Navigate comes with some Out-Of-The-Box apps that are at least good enough for a demo. They have a search box built in. Now where was that documentation .. There is a community board for Navigate, you might want to browse there.

No doubt we will be modifying the apps after we have the go-ahead from stakeholders.

cheers -- Rick

[TomU]

This is insane.  What a convoluted mess.

[STEVEG]

That's because it is.

[LawrenceS]

Unfortunately those links didn't work (I think they are to your company's installation of the help files), but I tried to search for the simple one on PTC's website and perhaps found what you were referring to on spaces and wildcards:

• https://support.ptc.com/help/windchill/wc110_hc/whc_en/index.html#page/Windchill_Help_Center%2FLclSrchCriteriaWildcard.html%23

From this I gathered some especially important points about INDEXED searches:

• "WC Index Search does NOT index spaces"! (emphasis added! 🙂)
• "Spaces are only used to split data into distinct keyword strings."

This still doesn't explain non-indexed searches though because:

• "WC database searches interpret spaces literally"
• "...non-indexed search...keyword term must account for every character in the value field, including any spaces."

According to this documentation I think that non-indexed attribute searches should contain the spaces.

[TomU]

Should I create a Windchill product idea requesting a change to this behavior?

• Would those in this discussion prefer Windchill never automatically add hidden wildcards to the search term?
• Would you prefer Windchill keep adding them, but also display the wildcards it added on the results page?
• Should Windchill always add wildcards before and after all search terms?

What is the preferred behavior?

For database performance reasons my preference is probably to perform an exact match with no assumed wildcards.  On the other hand, this is opposite what most people are used to and opposite how most web pages work, so there is a pretty good argument for always including wildcards before and after all search terms (unless of course the search term is in quotes.)  Thoughts?

[rleir]

@TomU @LawrenceS 

Tom:

I think we should start by identifying the documentation for search. It was scattered across several documents, articles and online help resources when I was looking a few months ago. It needs to be described in detail in one place and I should not be relying on my knowledge of Solr (especially since Solr can be customized to work differently in an app).

Then we should decide where search is done. There is the Keyword field, and below it in Criteria there is a name search and a number search. At the top right corner there is a quick search. Other places too? I suspect there is a difference in the wildcard handling (please confirm?). These should all work the same from the users' point of view. But my guess is that the Keyword search is done by Solr and the criteria search is done by a database? If they all work the same then sorry, please disregard this.

This might be a red herring: did search change from WC 11.0 to 11.1 to 11.2? If so the documentation should reflect this, not just in the patch release notes.

With the groundwork done, your question might have some clear answers.

thanks

Rick

[HJ1]

Then there's the bug factor. Or maybe it's because of the 'attempt to please all' -nature of search tools but our implementation does not hit the "Works according to specification" spot here, I don't know. However, if in search criteria I selected a Classification attribute and use that with Name the latter behaviour alters from what it's without Classifications and the boolean "AND" does not work. Just confusing.  This in 11.0 M030 CPS16.

[rleir]

@HJ1 So true. This could be largely a documentation problem.

Solr is designed to give you the best matches, in ranked order. It's idea of 'best' could be different from your idea of 'best', and the one result that you really want to see might appear on the second page of results.

This issue is compounded by the nature of Solr: it is possible (though exceedingly unlikely) for your admin to find the Solr config XML file in the WC server and change the search behavior. If there was a change in behaviour between WC 11.0 and 11.2, then I would be suspecting that PTC had changed this Solr config.

[lhoogeveen]

@TomU Absolutes may be too strong here. Index / keyword searches don't follow the normal rules of using wildcards because of spaces. For non indexed searches, any auto added wildcards should be displayed to users.

My preference would be for quick toggles that could also be used used in 'Saved Searches' or have preferences to control the defaults. Something like the image below:

[TomU]

True, I'm not taking into account the unique behavior of using Solr.  We don't currently have that installed so I'm not up to speed on all the nuances of using it.  Still, wouldn't it be better if Windchill worked the same everywhere, with or without indexing turned on?  When you go to Google to search for something, you don't have to give much thought to how to perform the search or what wildcards to use.  Anything in quotes is an exact phrase and everything else is just terms (assumed wildcards between everything.)  Why can't Windchill also be that easy to use?