iMIS 15 Desktop - Error during logon: 13 Type mismatch

Posted February 16th, 2009 by Henry Huey

If you encounter this error, the very first thing to check is whether you can login to the full web view. Desktop uses the Membership Web Service for authentication, and the service runs as part of the iMIS 15 install on the application server (the URL specified by key="ImisWebServerUrl" in web.config). If you can't login to the full web view, try restarting IIS. If that doesn't fix the problem, the iMIS 15 server installation needs additional troubleshooting.

A different login problem occurs when an invalid Host URL is specified in Desktop, at Logon / Set Host Location. This will generate a message box error containing a lengthy SOAP message; look for "The system cannot locate the resource specified.". If you see this, look for a typo in the URL, and also make sure your application server is online.

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

type 13 mismatch error - another thing to try

On February 18th, 2009 prushizky says:

While we've done several successful conversions now, we kept running into the '13 type mismatch' error with one database. (We are converting from 10.4, so we upgrade to 10.6, then 15.0.1871, then to the current release.) ASI Tech Support came up with a solution that got us past the problem (thanks go out to Chris Young):

----
Ok, this database is missing one of the IBO keys in the System_Params table. These will need to be rebuilt in order for logins to work correctly after the database has been upgraded to iMIS15.
Please follow these steps:

1) restore the 10.6 database
2) using query analyzer delete the ibo entries from the system_params table
delete from system_params where parametername like '%IBO_%'
3) login with the 10.6 desktop client as MANAGER!SA
4) Under File > System Setup > User Passwords select the MANAGER account. Make sure the access levels are set to all 8’s. 9 is not a valid access level, change them all to 8 (if not already). Save
5) change the manager password to a something you know and that does not contain special characters and is not manager.
6) run recreate and then update sql logins.
7) log out then login again as just MANAGER to test the account.
8) apply your new license with the casual users.
9) Prepare your staff users records per the upgrade doc.
10) make a backup of the database and try the upgrade again.

----

We had the MANAGER account authorization levels set to '9' for everything instead of 8, not sure why we did that or if it made a difference with the error.

Danger! Don't delete IBO_%

On February 24th, 2009 Bruce Wilson says:

It's a really bad idea to delete all the System_Params items named like IBO_%.

Two of these entries, IBO_Control.EncryptionKey and IBO_Control.HashKey are the secret keys used to encrypt credit cards and passwords, respectively. As I understand it, once these are deleted they cannot be recreated. (Ian Wann told me they are large random numbers, and not determined from the iMIS database.)

So if you delete these, all your passwords and all your stored credit card information are effectively lost.

Deleting the IBO_Control.Access record is safe... but probably unnecessary. iMIS assigns a new value automatically when you click "Update SQL Logins". When you click the button, iMIS warns you that your iBO applications will have to be restarted.

-- Bruce

aren't the keys re-created?

On February 24th, 2009 prushizky says:

We are converting from 10.4 to 15, so the conversion is in three jumps: 10.4 > 10.6 > 15.0.1817 > latest release. My understanding is that after we delete the iBO keys in 10.6, they will be re-created by the 15.0.1817 upgrade process. Is this still a cause for concern?

What Ian told me was that

On February 24th, 2009 Bruce Wilson says:

What Ian told me was that the values are created from a random value each time. So yes, the Encrypt/Hash keys will be recreated, but with a new value that can't be used to encrypt or hash to the same results as before.

-- Bruce

Tyep 13 Mismatch - Communication with db problem

On February 24th, 2009 mriley says:

I have found that almost any communications issue with the database can cause a Type 13.

One odd thing I have had happen is the .NET 2.0.50727 web extension was missing, and the site was set to .Net 1.

The site had been ok, I don't know how it lost .NET 2 but make sure that .NET 2 is set up right in IIS.

I just saw this error today

On August 31st, 2010 trobbins says:

I just saw this error today after rebooting the production app server. Restarting IIS took care of it.

iMIS Community