Skip to main content
L
LawrenceS18-Opal
18-Opal
March 27, 2020
Solved

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

  • March 27, 2020
  • 31 replies
  • 12147 views

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

Best answer by rleir

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

31 replies

B
BenLoosli23-Emerald III
23-Emerald III
March 27, 2020

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

L
LawrenceS18-OpalAuthor
18-Opal
March 30, 2020

Yes, detail pages show the identical attribute value

  • asm
    • lscheeler_0-1585577224554.png

       

  • .drw
    • lscheeler_1-1585577241646.png

 

This is very bizarre. 

L
LawrenceS18-OpalAuthor
18-Opal
March 30, 2020

And here are screenshots of the 2 searches:

  • Complete attribute (no wildcard stars):
    • lscheeler_0-1585578302624.png
  • Partial attribute with wildcard star replacing missing text:
    • lscheeler_1-1585578350608.png

 

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).

R
rleir17-PeridotAnswer
17-Peridot
March 30, 2020

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

    L
    LawrenceS18-OpalAuthor
    18-Opal
    March 31, 2020

    @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?

      L
      LawrenceS18-OpalAuthor
      18-Opal
      April 1, 2020

      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
        B
        BjoernRueegg17-Peridot
        17-Peridot
        April 1, 2020

        @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?

        R
        rleir17-Peridot
        17-Peridot
        April 1, 2020

        Hi Bruegg,

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

         

        Hi Lawrence, 

        thanks for exposing some 'interesting' Windchill behaviour.

        cheers -- Rick

          T
          TomU23-Emerald IV
          23-Emerald IV
          September 9, 2020

          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?

            R
            rleir17-Peridot
            17-Peridot
            September 10, 2020

            @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

              H
              HJ115-Moonstone
              15-Moonstone
              September 10, 2020

              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.

               

                Terms & ConditionsAccessibility statement