HPE Records Manager and HPE TRIM Forum
Showing results for 
Search instead for 
Do you mean 

Searches for records that have record types that are not in a specified set.

Occasional Advisor

Searches for records that have record types that are not in a specified set.

I have some code that successfully uses FilterRecordTypes to obtain records that have types that match those in a specified set.  Is there an efficient way of searching for records that have types that are NOT in the specified set?

6 REPLIES
HPE Expert

Re: Searches for records that have record types that are not in a specified set.

DO you have a sample of your code?

 

I could run it past the SDK support team.

**Any opinions expressed in this forum are my own personal opinion and should not be interpreted as an official statement on behalf of Hewlett Packard Enterprise**
HPE Expert

Re: Searches for records that have record types that are not in a specified set.

Or have you considered using a 'NOT' clause?

**Any opinions expressed in this forum are my own personal opinion and should not be interpreted as an official statement on behalf of Hewlett Packard Enterprise**
Occasional Advisor

Re: Searches for records that have record types that are not in a specified set.

Thanks for replying.

 

I have attached a file containing code that searches for records with specified record types.  Hopefully this will be reasonable self-explanatory but shout if it is not.

 

I am new to TRIM and have borrowed heavily from existing code so it may be that the method used is not a preferred approach. 

Occasional Advisor

Re: Searches for records that have record types that are not in a specified set.

It crossed my mind that this might be possible but being unfamiliar with TRIM searches was unsure how to modify the previously supplied method to negate the search and find records with record types that do not match the supplied set.

Honored Contributor

Re: Searches for records that have record types that are not in a specified set.

An alternate way may be as follows:

1) Load all Uris

2) Remove those in your list

 

Note your code has memory leaks. 

 

Here is my update to your code using the above logic:

 

		List<int> recTypeUri = new List<int>();
		RecordTypes tTypes = db.MakeRecordTypes();
		RecordType tType = null;
		while ( (tType = tTypes.Next()) != null ) {
			recTypeUri.Add(Convert.ToInt32(tType.Uri));
		}
                foreach (DocumentGrouping.DocumentType documentType in documentTypes.Values.ToList<DocumentGrouping.DocumentType>())
                {
                    RecordType t = db.GetRecordType(documentType.RecordType);
                    if (t != null)
                    {
			if ( recTypeUri.Contains(Convert.ToInt32(t.Uri)) ) {
				recTypeUri.Remove(Convert.ToInt32(t.Uri));
			}
                    }
                    else
                    {
                        log.WarnFormat("*** UNKNOWN RECORD TYPE *** \"{0}\"", documentType.Name);
                    }

                }

                //+
                // If there are no matching record types abort the search as otherwise we will find all records!
                //-
                if (recTypeUri.Count > 0)
                {
                    RecordTypes recTypes = db.MakeRecordTypes();
                    recTypes.SelectByUris((object)recTypeUri.ToArray());
                    search.FilterRecordTypes(recTypes);
                    search.Start();

                    documents = search.GetRecords();
                    int count = 0;
                    if (documents != null)
                    {
                        count = documents.Count;
                        if (count == 0)
                        {
                            documents = null;
                        }
                    }
                }

 

Highlighted
Occasional Advisor

Re: Searches for records that have record types that are not in a specified set.

That's an interesting approach.  It hadn't struck me that the MakeRecordTypes() method populated a list of all record types which was then filtered by the call to SelectByUris(). Can  you point out the memory leak you have spotted please?  

 

Thanks for your help!