Cross reference table for ArchivedQueue Status field

[Peter_Scaramuzz]

I found in the documentation in Appendix A regarding the the Status field of the ArchivedQueue. Is there a table in the database that contains a cross reference from the number to the textual queue value? I tried looking in the documentation and the database and could not find anything....

[Ansley_Ingram]

Hi Peter,

The translation of the status values is not stored in the database. You'd need to consult the Database Reporting Guide to translate the values.

Ansley

[Alex_French]

This brings up a question-

Is there a reason that Hyland doesn't maintain reference tables for status codes inside the database, so lots of queries could use joins instead of extensive case statements?

The same thing would be great for some of the binary flags also, though I'm not sure how that would best be structured to simplify the "...flags & 32 as foo, flags & 64 as bar..." query structure.

[Ansley_Ingram]

Alex,

The translation for any hard coded enumerations is maintained within the OnBase software code, not in the database. There are a variety of reasons that these enumerations aren't contained within the OnBase database with one of the most important being maintaining integrity of those enumerations (i.e. if we change something we'd have to change it in multiple places rather than one). For the most part, we do not expect customers to be interacting directly with the OnBase database and don't expect customers to have a need to translate the enumerations. For the information we do feel would be useful from a reporting standpoint, we document that in the Database Reporting Guide.

Hope that helps.
Ansley

[Anil_Arkatkar]

I understand that changing the strategy now is difficult. Moving the codes and their values into the database could be a pain for OnBase developers as all those codes will need to look into the database versus wherever it is hardcoded or being fetched from now. But I don't understand why the keeping the values in database would result in less integrity or any change in the value would need changes in multiple locations. As matter of fact, I think it other way. The values in DB would have worked as common vault for this data. I am dealing with so many systems and databases at my location (I am a DBA), and every system keeps this kind of data in database. Many times, I had also come across with the situations where management would like to have some analytical info from OnBase data, and I always missed this piece of data. As matter of fact I was shocked to find out that this is not in database, when first such analytical request was made to me by management. Just a suggestion: May be OnBase will come up with some robust reporting module, so that the DBAs or the systems admins do not need to run any queries/reports. Don't take my comment wrong way please. But I agreed with the original request and had same frustrations sometimes.