Home » blogs » JB's blog

iMIS 15 - Ability to track the User who modified a record ??

Posted November 7th, 2007 by JB

with the change of authentication methods between iMIS 10.x to iMIS 15.0 you can no longer from a SQL prospective know who the imis client user is who is performing the update/insert/delete. There are various third party triggers...etc that currently exist on iMIS databases that go ahead and insert lines into the Name_log table for one reason or another. The trigger whould know who the user is by parsing the SESSION_USER variable in SQL.

with imis 15.0 and the .NET form authentication the usefulness of SESSION_USER is removed because from the SQL prospective there is only one common user authenticated that is accessing the database.

Has anyone thought about a potentional workaround?

~JB

JB's blog | login or register to post comments | printer friendly version

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I think a related problem is

On November 8th, 2007 troberts says:

I think a related problem is that it's no longer possible for a system administrator to see who is logged into iMIS by looking at the list of sql users.

login or register to post comments

Change log and desktop client

On November 20th, 2007 Cameron Johnson says:

In 10.6, we have that problem where, when looking at the change log, any updates that came from the web (like a user updating her own account) are attributed the the SQL account used in making the ODBC connection.

If I read that correctly, iMIS 15 will expand that problem to the iMIS desktop client, too?

login or register to post comments

Change logging

On December 31st, 2007 Eric Means says:

Yes, this is somewhat of a problem in many of the current tables. The Name and Orders tables (and possibly others) at least have an UPDATED_BY column, which should give the iMIS username of whoever made the last update, but the Trans table (and I'm sure other tables as well) don't have this field.

As we move more to the .Net code in upcoming releases this should get significantly easier: every important table should have a CreatedByUserKey and UpdatedByUserKey field which will automatically be populated with the UserKey (foreign key to the UserMain table) of the user who created/updated the row. You'll also be able to add CreatedByUserKey and UpdatedByUserKey fields to any other tables you want, and as long as BOD is used to insert/update those values and those fields are included in the BO definition, it will automatically populate the fields on inserts/updates.

So in the short term, no, there's no really good answer for people who used to depend on the SQL user, if you're using an old-style table without an existing UPDATED_BY field. The good news is that we're aware of the issue and intend to address it architecturally in the future. And of course if your trigger is on one of those tables that has an UPDATED_BY field, you should be able to use that today.

login or register to post comments