Increase Keyword Limit of 250?

[Brian_Bartolazo]

I know it has been asked a bunch of times, but is there any reason why OnBase will use the char datatype when it creates the Keyitem tables versus using Varchar? Since the Char column is the limitation on why 250 is the maximum, I'm curious if there are any reasons why Varchar couldn't be used to leverage larger values?

We have some workflows that deal with customer complaints, so a summary of their letters is often used as a keyword to store on the complaint record. This is ultimately used to push to another system, but the summary is needed in the workflow to display to the reps so they are able to see what the complaint is about.

The problem is, the summary doesn't always fit within 250 characters. They can add another instance of the keyword, but it would be best to have it as a single keyword value.

These summaries are displayed on Unity Forms and as far as I am aware, in order to allow the input and display the field on a Unity Form it must be saved as a keyword.

I saw some other postings where people had mentioned E-Forms to link the larger values -- but I am not clear on how that exactly works. Wouldn't a E-Form still need to store a user-entered value in a keyword? Maybe I'm missing something, but I wasn't sure where OnBase would be able to store entered text anywhere but a keyword.

Again, I'm sure there is some technical reason why OnBase only uses Char columns for the datatypes, but if anyone has any clarification as to why that is the only option that would at least help me understand the limitation.

Thanks

[Ansley_Ingram]

Hi Brian,

The decision to used fixed length data types for Keywords was made many years ago and was largely related to performance over time as values change. Keywords are intended to be used for retrieval, cross-reference and evaluation logic and values that are actually useful in those scenarios are typically less than 250 characters.

For larger text strings, phrases, etc. - like the summaries you mention - you can store and display those on both Unity Forms and E-Forms as text without having to actually have them as Keywords. The actual content of the text is stored in the file in the Disk Group, rather than in the database. If the contents of these summaries is something that your users need to see when they are working with the documents, rather than something they need to search for, then a text field (Text Box or Multiline Text Box in Unity Forms) should give you the functionality you are looking for.

I hope that helps address the problem you're seeing.

Ansley

[Brian_Bartolazo]

Thanks Ansley.

Is there any way to retrieve the values of those plain text boxes on Unity forms when they are not mapped to a keyword? The users will enter and view them, but we also need to pull those values as well. For one, we will need to get the value of that textbox to send it to another system, which we do through a Web Service call through a workflow action. We'll also need to be able to report on the value through our SQL Reports. I think as long as we are able to get to the content of the text since it's stored on the disk group this would be a viable solution.

[Brian_Bartolazo]

I played around with the API and I determined I can pull the value through a Unity Script (assuming the properties don't have any limits for values -- didn't try that part yet).

It looks like this is stored in the XML on the File Server, so I can't think of any ways we would be able to report on this via SQL. If you know of any ways or if you can confirm that that isn't possible that would be helpful.

Thanks again

[Ansley_Ingram]

Hi Brian,
I'm glad to hear you found an API solution to pull the value into a Unity Script. I was thinking there may also be some sort of Workflow related functionality to do that.

As for the SQL reporting aspect - the text box contents are indeed stored in the XML on the file server, not in the database, so you would not be able to query this using SQL.

Ansley