SIMS on a Standalone
Ive currently done the following to get sims running on a standalone laptop
- Installed SQL Express 2005 onto laptop
- Installed SQL Manager for Express 2005 (not actually needed but useful)
- Copied s:\sims from original server (while database is inactive) to c:\sims on laptop (and shared on laptop as shared$. The local user then maps \\locallaptop\shared$ to s:
- Copied sims.ldf & sims.mdf to the laptop.
- Used dbattach.exe to attach the sims database to sql express using SA username/password.
- Installed SIMS.net on the laptop from s:\sims\setups (from the local machine)
- Changed the s:\sims\connect.ini to point to the local machine.
This is done as per notes http://support.capitaes.co.uk/websup...spx?KB=KB25354
I then try to login but get the following error message:
With correct username and password:
SIMS Connection failed for Login <user>, reason: 0
With correct username but wrong password:
Invalid user name/password
If I go into the SQL manager and reset the users password manually i get the same error:
Invalid user name/password
If I use the SQL manager to login I can use one of the sims usernames to gain access directly to the database tables etc but it just fails to login using the sims interface.
Any ideas how I can solve the login problem?
have you checked the sims and connect ini files that they are pointing to the right places
Both are pointing to the correct place.
This is also shown by the different error messages I get when playing with usernames/passwords.
I had exactly this problem a few days ago.
I tracked it down to the fact that the user Sql Server was running as didn't have permission to write to the registry. As per best Microsoft practices, it had minimum permissions. I added it to the local administrators group (it is a test system) and deleted then re-attached the database and it worked with no problem.
There was actually a message when attaching the database that it couldn't write a registry key, but it was buried in a mass of other statements about setting and unsetting database settings, and didn't flag it as a major issue.
The problem with SQL 2005 is that by default it's installed in a secure state, so you must turn on features or services, otherwise you will get errors like you describe.
Microsoft have made it a little complicated, but there are several versions of SQL 2005 Express. I would recommend you download SQL 2005 Express with Advanced Services SP2. It's the Advanced Services which are very important!
Once installed, navigate to Start > Programs > Microsoft SQL Server 2005 > Configuration Tools > SQL Server Surface Area Configuration.
Now click: Surface Area Configuration for Services and Connections
Hope this helps
Sounds like it could be that when you have attached the database the login for SQL isn't mapped to the database. If you're using SQL login then it needs to be mapped to a user which has permissions within the database. Also check on the properties of the SQL box that you are using Windows and SQL authentication (but if as you say you attached it using the SA password, you must already be).
Forgive my ignorance, i've no idea what i'm talking about where SIMS is concerned but that's how i fix that problem when i face that error with SQL.
Just checking - did you detach the database from the main SIMS server before copying the files over? - I believe the logins are stored in the master SQL database and not the SIMS one, and that you have to detach it to copy the relevant logins into the SIMS db.
I could of course be talking rubbish, but I've certainly seen all the logins' passwords get reset by copying the database files without detaching them first.
Thanks for all the suggestions. Originally I did not detach the database from the server as it was inactive (our old server had 2005 installed at christmas and we have just replaced the hardware as it was pushing 4 years old).
Using dbattach, after I copied the inactive database files across, it did remap the sql users to the sims database users but as SteveMC says if they are stored in the master database then this is probably my own fault for not detatching the database originally
Ill check permissions first and if that fails ill try activating the old database and detaching properly then reattaching. If that doesnt work ill try the SQL Server 2005 Express Edition with Advanced Services SP2.
Thanks all! Let you know how it goes.
EDIT: Looking at the old server, it looks as though the sims database has already been detached - im guessing this was done when we moved to the new server hardware.
What permissions can I actually check for sqlexpress? I have had a snoop round SQL Server Surface Area Confiruation and SQL Server Management Studio Express and cant find anything obvious then again SQL isnt exactly my forte.
Could find any permission related things - except on SQL Server Surface Area Confiruation but this refers to vista not xp (added myself as administrator anyway, no change)
Tried SQL Server 2005 Express Edition with Advanced Services SP2 - same problem.
The old DB must have been detached and reattached to new server properly or we wouldnt have a working system on the new hardware.
Its driving me up the wall, authentication is obviously working as I can login directly using sql management.
Through sims it appears authenticaion is also working as i get one error message if I type my username AND password correctly, but a totally different message if I type an incorrect password OR username.
The main SQL logins have been copied across so it appears the db was originally detached properly. When I attach the sims db I do end up with the main SQL sims_<name> usernames and the same within the sims DB. Main SQL usernames are mapped to the sims DB usernames.
Any more ideas?
Hate to point this out, you don't have a working system...
Originally Posted by Frazer
Just a thought but you did say you'd mapped SIMS as a shared folder in your first post, could it be that you have shared from the SIMS folder itself so instead of achieving S:\SIMS you're getting S:\ and then all the SIMS subfolders?
Also, have you tried:
Detaching the DB,
Stopping the SQL Server,
Deleting the SIMS.mdf and ldf from in the Data folder,
Starting the SQL Server,
(Oviously go and get a cuppa),
Then once all that is done run the Capita restore routine to get your Database in:
Use DBAttach /restoreui (from the appropriate directory of course). - To do this you'll need to have had the latest SIMSSQLApplicationSetup.exe run already.
(DBAttach /restoreui is used to attach a database which you made a backup of on your old hardware but it is sure to put the logins in properly.)
Failing this I reckon it could be an issue with the laptop not liking its own name (vaguely remember some bodge around with a hosts file a few years back), try enabling the Microsoft Loopback Adapter through Control Panel | Add Hardware, then using the loopback IP address (127.0.0.1) in the connect.ini.
If all else fails and they are both similar processors you could just image it!!
superfletch, perhaps I should make myself a little clearer.
(1)Old server. Dell power edge that used to run Server 2000 + SQL 2000 for our admin network (trust relationship to curriculum for teacher access to sims). Upgraded to SQL 2005 at christmas - all working fine.
(2)New Server. Replaced (1) with new shiney Dell in May (Server 2003, SQL 2005, member server on curriculum, all admin workstations moved to same network as curriculum) - working without problems to all admin & staff.
(3)Laptop (now VM ware until i sort the problem) - has the problems posted here.
The (1) is where I am getting my sims folder/sims database from as its much easier to do what I want, when I want without having to kick people off the live system(2). When I vnc into (1) and check SQL 2005 Manager, the sims database is not attached. I assume this was detached properly using the capita dbattach by westfield when the database was moved to (2) in May and left detached.
Simstest is the name of the vmware workstation and sqlexpress is the name of the sql instance.
The folder structure on the test system is as follows:
c:\shared <-- shared as Shared$ with sims folder inside (standard westfield centre setup)
\\simstest\shared$ mapped to s:
c:\program files\sims\sims .net\connect.ini redirects to s:\sims\connect.ini
s:\sims\connect.ini points to simstest\sqlexpress & sims database
I havent tried using 127.0.0.1 but I did try using (local) in the sims.ini which should be the same, ill give this a go.
The /restoreui is new to me so I will try this too.
Thanks for the suggestions.
How I resolved this was to give the Sql Server user higher permissions.
Have a look at which user Sql Server is running as in Administrative Tools/Services. It will either be SQL Server (MSSQLSERVER) or SQL Server (INSTANCENAME). Add this user to the local administrators group. Re-start the service and then try attaching the database using DbAttach.
Once it's working you should be able to reduce the permissions level again, but I haven't tried this since my instance is a test system.
Restoreui has worked for me in similar situations recently - it's worth a go.
I have had similar problems, but now when I export the curriculum from NOVA it says access denied - and I have every access right!
Fixed! (rpwillis suggestion)
- Used DBAttach to detach the database from SQL Server on the latop/vmware.
- Stopped the sql server inside SQL Server Management Studio Express
- Created a new xp user called sqlserver, added to administrators group.
- Computer Management -> Services and Applications -> Services -> Properties of SQL Server (SQLEXPRESS) -> Changed 'Log on' to use the new sqlserver account.
- Restarted the SQL instance by SQL Management.
- Attached the database using DBAttach (if you get errors, you may need to start again from the top but copy across the "Microsoft SQL Server\MSSQL.1\MSSQL\Binn" folder from the original server - dont overwrite any files)
I did try reducing the sqlserver to a normal user but the service wouldnt restart so ive left it as administrator at the moment.
If you need to use nova, then you will have to copy (from original server) s:\snova to your new s: drive.
Thanks for the help people.