inoracker
Novice

Populating a list view with full names

Hi all,

 

Currently, some of our apps have an "Audit" list view that displays actions taken in a case.

 

We have a problem with the speed of returning the user's full name as we only store their userid in the database.

 

In other circumstances, we usually use SmartObject association and a limited set of users to reference, and the speed of returning names for that is fine (we do a nightly extract which pulls all user details in to a table from AD)

 

However, for the "Audit" , the users displayed in the list could be anyone in the organisation (1000+ people).

 

The current idea is to create a linked server to the extract table and write a stored proc for these types of list views, so the pulling back of names can be handled server side.

 

How does everyone else get around speed issues when returning names from AD or other sources?

 

Thanks,

 

Rebecca

0 Kudos
Reply
1 Reply
NathanBrown
Apprentice

Re: Populating a list view with full names

It was recomended to me to make an SP in another database (same SQL Server just different db) that would join the log tables with the user tables directly from k2.

 

Something like this:

SELECT TOP 1000 [ProcInstID]
,[ActInstID]
,[User], i.DisplayName
,[Date]
,[Descr]
FROM [K2].[ServerLog].[ActInstAudit] a WITH (NOLOCK)
LEFT JOIN [k2].[Identity].[Identity] i WITH (NOLOCK) ON i.FQN = a.[User]

 

This is is probably not the table you were after, but you get the picture.  Again we put this into an SP in another db so we are not modifying the K2 database, but still accessing it.  If there is a K2 schema change naturally have to change it, but that is not a big deal.  You can then expose this as SMO, etc.

 

Note, this doesn't handle any of the security handling so you may need to build in that logic depending on your needs.  That is how I get around most K2 related queries.

 

For our code, we only store ID# (think employee ID) in all of our tables and we do have to Sync our AD to a database table with user's names.  We use custom code to pull fields from AD and plunk them right into a table.  I think this is better than using the Username, which can change.

 

 

 

 

0 Kudos
Reply