Home » discuss » Public forums » Developing for iMIS

Web user cannot create a logon/password

Posted September 8th, 2009 by eja144
|

We are using iMIS version 15.1.1 and IIS7

Our Web users cannot create their logon/pasword. The error they get is that the username is already in use but on the server we get a SQL timeout error and have confirmed that the username has not been used.   The contact is created correctly and our customer service reps can add a logon/password for them using the desktop.   But most of our potential customers give up at that point.  When we converted our previous data base I wrote an ASP.NET application that used the WebService to create new logon/passwords for old customers.  It used the CreateiMISUser operation - this worked fine for about 13,000 customers.  Before the CreateiMISUser operation was called the program logged in as Manager.

When I run the profiler to capture what is happening on the SQL server I see a couple of queries using the GUEST account.  It returns several result sets.  Then it times out.  The only place I have found that sets the DataSource.iMIS.Connection string is in Asi.Workflow.Services.exe.config and it is set correctly there.  In the Web.config file I tried setting the connection string but I get an encryption error.  Everything else works OK.  The user can change their address and personal information - just not their username or password. 

Does anyone have an idea of where I can look to solve this problem?  Is there someplace to configure the GUEST account? or is a different account used to enter the logon/password?  The Asi.Workflow.Services.exe.config file lists an ASPNET for the Authenticate.Anonymous.UserId but the Web.config has GUEST.

Thanks

‹ eSeries Cold Fusion LoginStatistics packages that work for eCM/wCM ›
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.

Check DBRepair

On September 8th, 2009 Bruce Wilson says:

Check the DBRepair utility, specifically the items about synchronizing NetContacts.  It could be there's something out of whack.

For that matter, you might want to use the new Purge utilities.  These seem to be for clearing out contacts you don't need anymore, so your license count is more accurate.  Could be you have enough orphaned entries out there to cause a problem.

--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.

login or register to post comments

RE: Check DBRepair

On September 9th, 2009 eja144 says:

 

Thanks for the suggestions.  Our DBA says the NetContacts were all synchronized.  We should have about 15,000 contact licenses left so that probably isn't the problem.

login or register to post comments

You might also check to see

On September 9th, 2009 Eric Means says:

You might also check to see if the SQL process is getting deadlocked, or change the value for OleDbCommand.CommandTimeout in web.config. (I would guess the deadlock is more likely than the CommandTimeout being too short, though.)

You cannot update the web.config file's connection string because it's encrypted; you would need to decrypt it to make such changes.  (You can do this by running "aspnet_regiis.exe -pdf connectionStrings physical_directory" where physical_directory is the full path to the Program Files\ASI\iMIS15\Net folder.)

login or register to post comments

RE: You might also chekc

On September 9th, 2009 eja144 says:

Thanks for the info about decrypting connections strings and deadlock suggestion.  I checked and the string is correct.  I think dead locking might be the problem.  While it is waiting to time out I ran sp_lock in SQL Server Mangement Studio and see three lines that normally aren't there.  It says that Name_Security and UserMain are locked.   Name_Security is using Index 0 on the table and index 1 on the page.   How can I trouble shoot a deadlock problem on Name_Security?

Thanks

login or register to post comments

You may need to use

On September 9th, 2009 Eric Means says:

You may need to use SQL Profiler to run a trace of the database while the user credential creation is going on. If you can get a trace, you can figure out which command is locking (and if you can provide the entire trace, we should be able to modify the code to avoid the deadlock).

login or register to post comments

Not necessarily a deadlock

On September 9th, 2009 Bruce Wilson says:

The output of sp_lock doesn't indicate deadlocks, just locks.  SQL uses locks heavily to make sure operations don't interact with each other.

Blocking is when one process can't start something until another process finishes.  This is normal and happens frequently, with no harm unless the first process takes a long time to complete.

A deadlock is when two processes are waiting for each other.  SQL detects these and clears them out quickly, so it's highly unlikely you saw them in sp_lock.

Looking at the specific values you saw:

Name_Security / TAB / 0  is a table lock.  It just means the table is in use by this connection.  The table lock prevents another connection from dropping the table or performing major structure changes on it.  Nearly every interaction with a table will create some kind of table lock.  (The 0 is meaningless for a table lock.)

Name_Security / PAG / 1  means the query is interacting with index 1, which is iName_SecurityWEB_LOGIN.  Index 1 on every table is the clustered index.  Any query that can't use another index will use the clustered index, or index 0 (heap index) if the table isn't clustered.  A page lock means that some page is being read.

In the output from sp_lock, the field that indicates blocking is when Status = WAIT.  This indicates a lock waiting for another to be released.  You can usually get the same information more easily from sp_who2, looking at the BlkBy column.  If the column is blank for all rows, then no blocking is taking place.

 

--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.

login or register to post comments

It's also possible to get a

On September 9th, 2009 Eric Means says:

It's also possible to get a "soft" deadlock, where iMIS has two connections active, one of which is trying to access a table that is locked by the other, and iMIS is waiting on the second connection before it finishes with the first. (This is generally accidental, as we try hard to avoid doing that). SQL Server cannot detect nor avoid these situations, which is why I suggested a trace.

login or register to post comments

Thanks for your help.  I

On September 9th, 2009 eja144 says:

Thanks for your help. 

I decided to simplify the problem and not try to create a new account but only modify the username (which also times out).

I didn't see anything in the profiler that looked like it would attempt to update name_security or UserMain.  I'm told triggers don't show up in the Profiler though.  I did see some queries trying to get role information that returned nothing and I'm wondering if that is normal.  It is trying to get RoleKey and UserKey.  Another query tries to get PropertyNames, PropertyValuesString, and PropertyValuesBinary by calling dbo.aspnet_Profile_GetProperties and passing in the UserName.  That also returns nothing.   Then it calls BAEImisNameSecurityGet  passing in the NameID and that returns a record.  After that I couldn't see anything in the profile trace related to updating the username.

Tomorrow we will install a fresh version of iMIS on a seperate server with the Public View and an empty database and see if we can get iMIS to create accounts and update usernames/passwords.   Once that is working I can run the profiler and see what it looks like when it is working.

 

login or register to post comments

Same Issue

On October 29th, 2009 MikeMcCormack says:

I having the same problem wtih two separate databases.  One is using IIS7 and the other is IIS6.  When you installed a fresh copy of imis and an empty daatabase did you have the same problems?  This problem didn't exist until I upgraded to patch 3632. 

Mike

login or register to post comments

I think I found the problem

On October 30th, 2009 eja144 says:

iMIS suggested I run the profiler and wait until it timed out and then send them the results.  When I did that I found the query that appears to be the problem.  It was doing a full outer join between the tables in Name_Security and UserMain. In our production DB the Name_Security table has 227,686 rows and the UserMain table has 9,727 rows.  When I ran that query seperately in the query analyzer it took over 4 minutes to run which is why it timed out.  When we restored an empty database the problem went away because we only had a few rows in those tables.  We were able to rewrite the query so that it only took a few microseconds and I sent that to iMIS.  It is interesting that our Customer Service Reps were able to create usernames and passwords using the Desktop so it appears that the Desktop isn't using the problem query but the Public View and Web View are.
 

iMIS moved the priority of the issue to high on October 19th and they are trying to get the fix into the next release but can't make any promises.

 

login or register to post comments

Query Name

On October 30th, 2009 MikeMcCormack says:

Would yoo mind sharing the query name that was causing this issue?

login or register to post comments

It's not an IQA query, it's

On November 2nd, 2009 Eric Means says:

It's not an IQA query, it's a query executed by the application. Unfortunately there is no workaround.

Eric Means
System Architect, ASI

login or register to post comments

Upgrade the only way to fix this?

On December 21st, 2009 Derrick Strom says:

I have a client who just did a production upgraded to 15.1.2.4370 and this is an issue.  We've done some custom development on the project and they are getting ready to take a second website live.  Was the fix to a stored proc we could apply to the .4370 version?  If the client has to upgrade and retest all the business processes and the custom development this will seriously impact the budget.  The first in production can't create new logins and the golive date of the second website would be in jeapordy with a new upgrade to 15.1.2.4972.   Can you elaborate on the fix for this?

login or register to post comments

RE: Upgrade the only way to fix this?

On December 28th, 2009 eja144 says:

 

15.1.2.4730 was the version we upgraded to that fixed our problem. 

The version that had the problem for us was 15.1.1.3286 and it looks like it is fixed in version 15.1.2.4730

When a user was creating a new username and password a check was made to make sure the username was not already in use.  That database check would time out for us because we had a lot of users in our database.  I don't know of anyway to modify the sql query that was making the check but it looks like they fixed it in version 15.1.2.4730

login or register to post comments

The latest release fixes this problem

On December 17th, 2009 eja144 says:

We just upgraded to iMIS Version 15.1.2.4730 and it looks like iMIS fixed this timeout problem.

login or register to post comments