Guarantee order of multiple keywords.

[Jacob_Morrison]

We have a document type that is indexed with a Title keyword.  This keyword is an alphanumeric keyword set to the max length of 250 characters.  However, these documents are of legal nature and the titles tend to be very verbose, sometimes exceeding 250 characters.  In this case, the user splits the title between multiple instances of the Title keyword.  

We are developing a report for them to display the document index, including the Title keyword.  Is there any way to make sure the order of the Title keyword values for a given document are displayed in the proper order?  We are finding that the second part of the title is often displayed before the first.

[John_Anderson4]

Short answer: not really

I'd probably recommend splitting it into multiple keywords (Title, Title 2, Title 3, etc. as needed)

The only other thing I can think of is using a Multi Instance Keyword Group - those should retain the correct order - but this isn't really the intended use case for them.

[Matt_DeFaveri]

Hi Jacob,

As John took the short answer, I'll regale you with the long one!

We don't actually store the order that multiple instances of single-instance keyword types are indexed in the database, so it's not possible for us to list keywords in the order they were indexed. Depending on the environment, the way data persists on the disk and how database indexes are pointed, multiple instances of a single-instance keyword type may or may not return in the order those values were indexed.

Essentially, OnBase doesn't control the behavior of these query results.

You could use a multi-instance keyword type group to resolve this issue, with the 'Title' keyword as the only keyword present in the MIKG, then add multiple instances of that MIKG to the document keyword list. This would ensure that the titles always appear in the correct order, as we use an additional database column - 'recordnum' - to sort and order MIKGs. This same column is not used when retrieving multiple instances of a single-instance keyword type, which is why the order appears so erratic. SQL decides the most efficient query to run and returns whatever results it finds in whatever order it determined was the most efficient to find them in.

Hope that answers your question. Feel free to contact your first line of support if you need any additional clarification.

EDIT: Just to clarify, the MIKG "solution" described above really isn't a solution - it's more of a workaround. If you need to search on long strings of text, our Integration for Autonomy IDOL is best suited for that purpose.

Thanks,

Matt DeFaveri

Technical Support Associate Analyst

Hyland Software

[Thomas_Reu]

Matt,

This thread reminded me that my clients wanted me to ask if Hyland is planning on allowing more than 250 characters in a keyword anytime soon.  After all sqlserver allows up to 2 GB in a field and has done so for years.  Granted, I freely admit, that 2GB is more than excessive for what OnBase is managing and I don't even want to think about the performance issues it might create.  However, only 250 chars seems so little that insufficient may not be a harsh enough description either...

Regards,

Tom