cancel
Showing results for 
Search instead for 
Did you mean: 

Getting all Documents Added or Modified to OnBase during a Period of Time

Paul_Ivany
Champ in-the-making
Champ in-the-making

Using the Unity API I need to retrieve a set of documents that were either added or modified during a period of time.  I am using a custom query and I am querying on Date Entered.  Would this be the best approach to get documents that were both added or modified (revision) during this period of time?

1 ACCEPTED ANSWER

Nevin_Steindam
Star Contributor
Star Contributor

The Document Date defaults to the date the document was stored, but OnBase allows it to be changed. And the Document Date does NOT reflect the dates of more recent revisions (unless you take it upon yourself to update the value).

I see three options. None of them are perfect:

  1. Set up your processes to enforce the rule that the DocumentDate (or a chosen keyword) always reflects this information. You CAN'T enforce that if users are allowed to do one-off imports and revision updates through the clients. However, if documents and revisions are always added through Workflow actions, other API code, Advanced Capture, etc., then you can control it. This would be the "best practice" if possible, because you're tracking a date that obviously has business value for you and is needed for searching.
    • My guess from your description is that you can have some confidence that the DocumentDate was left unchanged from the date stored, but you already have revisions in the system that didn't have their date recorded.
  2. If you are working with a very small number of documents, you can do what Brandon suggested above: Query on ALL documents that MIGHT fit, and then check the dates one by one. Documents have a "DateStored" property that always tells you the date it entered, regardless of whether the Document Date was changed. Documents also have a list of "Revisions", and each Revision has a "Date" property with the date that it was added.
    • Unfortunately, querying for EVERY document and then checking this information quickly becomes inefficient and impractical. It doesn't sound to me like you are just checking against a small set of documents. (Note: OnBase doesn't make these fields directly searchable because they aren't needed by most people. It's assumed that if they do have business value, then there will be processes similar to the ones mentioned in option #1.)
  3. Though you can't use the API (or a client) to search against DateStored or Revision.Date, those values DO exist in the database. You can figure out the appropriate SQL query and get your list that way.
    • I never like to suggest database queries as a solution, but because this is a read-only query, it is permitted. And unless my other assumptions were wrong, this is probably the only option left to you.

If at all possible, I would try to structure my solution around option #1.

View answer in original post

9 REPLIES 9

Brandon_Miller
Champ on-the-rise
Champ on-the-rise

If you're using the Unity API you can just parse Date Entered into a DateTime object. .NET allows you to use conditional operators (">", "<", ">=", etc) on DateTime objects. So, it would look something like


DocumentList.Where(i => i.DateEntered > minDate && i.DateEntered < maxDate).ToList();

Paul_Ivany
Champ in-the-making
Champ in-the-making

Thanks Brandon.  I've included my code below.  I am using the documentQuery.addDateRange() in the Unity API to add the time period in which I want to get all documents added/modified in OnBase.  I'm just wondering if using the Date Entered field would get me all the documents that were added/modified during my date range.

Oh, I understand what you're trying to do now.

What data type is strStartDate and strEndDate? Per the API reference, those parameters need to be a DateTime object, not a string.

Nevin_Steindam
Star Contributor
Star Contributor

The Document Date defaults to the date the document was stored, but OnBase allows it to be changed. And the Document Date does NOT reflect the dates of more recent revisions (unless you take it upon yourself to update the value).

I see three options. None of them are perfect:

  1. Set up your processes to enforce the rule that the DocumentDate (or a chosen keyword) always reflects this information. You CAN'T enforce that if users are allowed to do one-off imports and revision updates through the clients. However, if documents and revisions are always added through Workflow actions, other API code, Advanced Capture, etc., then you can control it. This would be the "best practice" if possible, because you're tracking a date that obviously has business value for you and is needed for searching.
    • My guess from your description is that you can have some confidence that the DocumentDate was left unchanged from the date stored, but you already have revisions in the system that didn't have their date recorded.
  2. If you are working with a very small number of documents, you can do what Brandon suggested above: Query on ALL documents that MIGHT fit, and then check the dates one by one. Documents have a "DateStored" property that always tells you the date it entered, regardless of whether the Document Date was changed. Documents also have a list of "Revisions", and each Revision has a "Date" property with the date that it was added.
    • Unfortunately, querying for EVERY document and then checking this information quickly becomes inefficient and impractical. It doesn't sound to me like you are just checking against a small set of documents. (Note: OnBase doesn't make these fields directly searchable because they aren't needed by most people. It's assumed that if they do have business value, then there will be processes similar to the ones mentioned in option #1.)
  3. Though you can't use the API (or a client) to search against DateStored or Revision.Date, those values DO exist in the database. You can figure out the appropriate SQL query and get your list that way.
    • I never like to suggest database queries as a solution, but because this is a read-only query, it is permitted. And unless my other assumptions were wrong, this is probably the only option left to you.

If at all possible, I would try to structure my solution around option #1.