Why would Quick Search work for Parts but not Documents

I have a client that is reporting that Quick Search is not working correctly for Documents in their system. A quick search returns related changes, but not the documents themselves. And this is only happening for documents – a search on a part works as expected. And an advanced search works as expected, but users use the Quick Search far more often.
 This started after a data migration was completed. I did drop and recreate the CTX indexes and triggers using DataLoad, but the issue persists. They are running on Agile 9360 RUP2.

No Files Were Attached
Kevin Cummings Agile Angel Asked on September 10, 2018 in Product Collaboration.
Add Comment
6 Answer(s)

Hi Kevin,

Did you try exporting and importing the dmp file?

keithrust Agile Angel Answered on September 10, 2018.
Add Comment

Hi Kevin, trying seeing if Oracle Doc ID 2213158.1, Doc ID 2251189.1, or Doc ID 1271285.1 help at all.  I remember reading about how basic and advanced searches can differ and can have issues.  Try those Doc IDs for some possible hints. That’s peculiar too – do you have a screenshot of this search?

Matt Paulhus Agile Angel Answered on September 10, 2018.
Add Comment

If you create a document from the client does a quick search find it? I assume you did an averify report.

Steve Jones, the PLM Doctor Agile Angel Answered on September 10, 2018.
Add Comment

And I got a better explanation from the client as to what is really going on.
 If you search for the document number, Quick Search works just fine (as I found out). If you search for the legacy number (yes, they renumbered *everything*), it does not find the document. Note that the legacy number is contained in the document description, so it SHOULD be found using Quick Search, as that field is included in the CTX index. And in fact, Quick Search usually returns 1 or more changes that contain the legacy document number in their description. So it is working as expected for changes.

 No, Keith, the database has not been exported/imported. I plan on trying that at some point in time, but since the load is being done on their system, this is not normally being done as a matter of procedure. But it is worth a try to see if things get cleared up.

 Yes, Matt, I have read through the various documents you showed and they did not offer much. I know the CTX indexes are used by Quick Search, and so they were dropped and recreated using DataLoad. I also tried the scripts I use for importing a database, but no luck there either.

 Yes, Steve, a new document with the same setup (legacy number at  the end of the description, preceded by “Legacy #”) does work with Quick Search And yes, Averify has been run several times, and showed nothing concerning CTX (or any other kind of) indexes.

 The really strange part is that Quick Search works as expected for Parts, but not for Documents. There is no good reason for that, as both are covered by the same CTX index on the ITEM table, which looks at both item_number and description. Then again, description is usually shown from the REV table. If I look there, yes, the description field for the document number does contain the legacy number value (although the description field in ITEM does not – for either Parts or Documents). Since I dropped and recreated all of the CTX indexes, it should not matter.    Which  is why I am scratching my head and asking for help…………..

Kevin Cummings Agile Angel Answered on September 11, 2018.
Add Comment

There is a CTX index on both the item and rev description columns. One of those should work unless the rev flags or item change are not set so you are not getting the latest rev in your search. You are close. It seems related to the data (load), not the index. Something is prohibiting the re-indexing from picking up the right data or finding it in the latest rev.

Steve Jones, the PLM Doctor Agile Angel Answered on September 11, 2018.
Add Comment

<sigh>   As usual, operator error (well, kind of).
 Early on, they had only wanted Parts to have the legacy number in the description, so the query to do so had that limitation in the where clause. And then later, I needed to make sure that the description in REV reflected the legacy number as well, but that query did not limit to only Parts. So when viewing the data, the legacy number showed up in the description for both Parts and Documents.  But for documents, it was not in the ITEM.DESCRIPTION field.
 Apparently when running Quick Search, it does not look at the REV.DESCRIPTION field, but only at the ITEM/CHANGE/etc. number and description fields. So you could see the correct values, but Agile would not search on them. I updated the descriptions in the ITEM table, dropped/created the CTX indexes, and now all is well.
 Note to self – Quick Search only looks at object data attributes, and not related data attributes.

Kevin Cummings Agile Angel Answered on September 11, 2018.
Add Comment

Your Answer

By posting your answer, you agree to the privacy policy and terms of service.