July 19, 2013 at 2:55 pm
Explain more please.
July 19, 2013 at 3:11 pm
Thank you sir. Yes, i know where the connection string is, and it is set up correctly i believe. The reason i am saying this is because i use the very same string, switching between restored .bak files, (searching for the latest one), and some of the very early ones does connect ok. (at the place where you edit the connection string, there is an option to test the connection to sql, and it is ok across the board, backups that work, and the ones that don't.
It seems that the backups went bad at some point, which makes me think again about the hardware failure. Is a tool to repair the salvaged .mdf file an option? I can log in to sql ms with the said user.
1.OK
2.OK
3.OK
4.OK
5.ole error
July 19, 2013 at 4:09 pm
I reviewed the thread, and all I can make out is that your application produces an error when you try to connect. This does not have to be corruption, it could just be a configuration hiccup.
Connect to the database through SQL Server Management Studio and run DBCC CHECKDB. Preferrably with the database restored from the backup. Post the output here.
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]
July 19, 2013 at 5:07 pm
calvo (7/19/2013)
So confusing.You've restored from a backup successfully.
You've attached the .mdf file successfully (what about the .ldf?)
Seems like it should all work but your application cannot connect.
Have you remapped the users in the database to the new logins you created when you stood up the new instance?
USE <database>ALTER USER <user> WITH LOGIN = <login>
This will map your database user to the login that the application is using to access the database.
Go back and re-read this. Google SQL orphaned users. Database users are mapped to SQL server logins. Those logins are in the master database, which is still on the old dead server.
You can prove this is the issue by trying to connect to the database with the application account.
July 20, 2013 at 6:10 am
Thank you all. The issue is resolved. I had to restore the databases in reverse order from way back, the moment i skipped one, i got the ole error. Example i could nor restore 15/07 on its own without an ole error (app side). When i restored 15/07 after 10, 11, 12, 13, 14 first, it worked. I upgraded the database to a more stable version of the app. Much better now and all data is intact.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply