Jump to content

Recommended Posts

Posted

@timbo343 I did the same as what you're trying to do last year. It worked surprisingly well, took me only a morning and saved a lot of money.

 

I used the database migration tool as follows...

 

Run it on the old server and migrate the database to a file (in my case SQL2008).

Copy file to new sever.

Run migration tool again on the new server - file to new SQL instance (in my case SQL2012).

 

I then installed sims on the new server and it happily connected to the new database. Then you just need to sort your DMS stuff and the connect.ini

 

Support net is full of documentation for this.

 

I have heard of the issue with passwords, but to be honest I thought this had been sorted some time ago and the database migration tool (using it twice to go from server to file to server) should take into account this issue.

 

Capita wouldn't give me anything to help migrate InTouch. I had to pay them for that bit.

  • Thanks 1
Posted

Login to SIMS on 2008 create a new backup from system manager. Use the dbattach in the 2014 BINN folder and restore that over the top of the exisiting DB. That should work.

 

On the new server you have two connect ini ? local in program files (should say redirect) and the one in the shared folder? Do they both point to 2014?

Posted
@timbo343 I did the same as what you're trying to do last year. It worked surprisingly well, took me only a morning and saved a lot of money.

 

I used the database migration tool as follows...

 

Run it on the old server and migrate the database to a file (in my case SQL2008).

Copy file to new sever.

Run migration tool again on the new server - file to new SQL instance (in my case SQL2012).

 

I then installed sims on the new server and it happily connected to the new database. Then you just need to sort your DMS stuff and the connect.ini

 

Support net is full of documentation for this.

 

I have heard of the issue with passwords, but to be honest I thought this had been sorted some time ago and the database migration tool (using it twice to go from server to file to server) should take into account this issue.

 

Capita wouldn't give me anything to help migrate InTouch. I had to pay them for that bit.

 

Ive been working on copies and backup copies of the database. I can see it taking only a morning as i think im nearly there but im scared to run the migration tool on the live database as i dont know what it will do. I know i can export it to a file when done, what will happen to the live data that is in use, will this get affected? I want to still.use the data on the live system as this is just a test at the moment.

Posted
Ive been working on copies and backup copies of the database. I can see it taking only a morning as i think im nearly there but im scared to run the migration tool on the live database as i dont know what it will do. I know i can export it to a file when done, what will happen to the live data that is in use, will this get affected? I want to still.use the data on the live system as this is just a test at the moment.

 

 

If you run it as I suggested the original server instance is not touched. Only the exported file is upgraded. I think you need users out though.

 

Check latest supportnet documentation but I'm 99% sure you'll be safe. I liked this method because it left my old server running if I messed up.

Posted
If you run it as I suggested the original server instance is not touched. Only the exported file is upgraded. I think you need users out though.

 

Check latest supportnet documentation but I'm 99% sure you'll be safe. I liked this method because it left my old server running if I messed up.

 

I might have a go tonight if i've got time, don't really want to do it when i get in from the pub... although that would be interesting :p, might give me a bit more courage and confidence lol. I didn't know if the migration tool touched or did anything to the data on the old server but by the sounds of it all it does is export the data ready for SQL2014 which i'd transfer to the new server.

 

I would run it now but staff are still logged in to SIMS.

Posted (edited)

Oh well, here goes!!

 

Back up SIMS Database - Done

 

Migration on existing/live server done.. made sure database is detached - done

 

Copy database files (ldf and mdf) to another location and rename existing database files in SQL folder to .old - done

 

use DBattach to attach database files back into the instance - done

 

Database successfully attached to old instance - done

 

try to login - waiting.... waiting.... waiting... and breathe!!! im back in the database on the old server... thank the lord.. no early start for me tomorrow!!

 

 

 

Just trying the migration on the new test server now.. migration finished,

 

make sure the connect.ini file is correct - done

 

Login to SIMS on the new test server - seems to be taking a while to load - not got the invalid username or password box or incompatible database box yet ... buggar, spoke too soon - incompatible database!

 

Now on the new server I'm getting "SIMS connection failed for login [username], reason: 0" even thought the connect.ini file is pointing to the correct location.

Edited by timbo343
Posted

Sorry it didn't work out for you. Is there any reason you are doing this on an evening/weekend rather than waiting a week or two and making it first job for the holidays?

 

When I used the upgrade tool for the migration I didn't detach anything. It needs the live SQL DB to use the tool. I think the migration tools takes into account the authentication issue. It would make sense, because even if you're not moving server - you are moving SQL instance and the logins need to be accounted for.

 

Read the first document that comes up here: https://myaccount.capita-cs.co.uk/search/All?q=database+migration+sql+2014&sort=relevance#

 

It explains how to migrate the sql to a new server - the only added thing you need to do is actually install and configure sims on your new server. I combined the above document (although I used the 2012 version) with the installing a sims server document to make it work here. I read and read those documents and wrote a flow chart of which steps I needed to do in what order.

Posted

Im one of these people that once an idea has come into my mind i need to carry it out hence doing it now.

 

The migration tool (SQL2014) backed up the live SQL database, then copied the data, detached the database and then did something else which is why i was praying that the live SQL database would let me log back in.

 

I re-read your notes on your migration and i had Installed SIMS before attaching the database so once the database was attached i renamed the existing SIMS install folders to .old and reinstalled SIMS.

 

I've got a copy of the link you suggested reading, ive been reading and re-reading this every time i do the migration into the new instance.

Posted

Is the new server running the lastest (or the same) version of SIMS as the old server? What version of DBattach are you using on the new server?

 

"Login to SIMS on the new test server - seems to be taking a while to load - not got the invalid username or password box or incompatible database box yet ... buggar, spoke too soon - incompatible database!"

Posted

Reason 0 means it can't associate that login with an account. Make sure SQL browser is running and the SQL service allows named pipes.

 

As you've migrated it might of lost the passwords for the usernames. Seen this a fair few times on the migrations I've done. You will need to reset the sysman password and then login with that and check what the users have as a password?

Posted

Just looked into the Reason 0 error, the Server for that instance has stopped and wont restart - thank god this is a test server.

 

So I re-ran the migration tool using Run as Administrator, imported the .bak file from the early hours of this morning and created a new instance within the migration tool. Its completed creating the instance TEST and database SIMSSHS. I have updated the connect.ini file and im getting incompatible database.

 

Something has seriously gone wrong.

Posted (edited)

YAY!!!!!!!!!!!!!!!!!!!!!!!!!!!!

its working now on SQL2014

 

At the moment im using Solus2 but the LA have asked us to move over to Solus3.

Edited by timbo343
Posted
........ #@*%$&£$*&%^!!!!!!!!!!!!!!!

 

Existing server 7.162, new server 7.164.

 

I'd turn it off and on again, just for good measure! ;-)

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...