July 19, 2013 at 10:26 am
I need advice, would be straight forward for most of you. i have a 1 week old .bak file. Then, hdd failure came. i re installed the same sql (2008), restored ok. The connecting application provides error ole80040E14. I assume, the db is corrupt, and i need to repair the mdf file with a tool, expensive. Database 1.3 gb, but containing gold. Any resopnse?
July 19, 2013 at 10:30 am
What's the text of the error the app gave? Most people don't memorise complex error numbers.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 19, 2013 at 10:40 am
Thank you, none, it stops. When i try to run a database upgrade, (to attempt opening with a different version of the application), i get denied access. Does this mean for sure(ish) that the database file is corrupt / broken? same symptoms when attaching the mdf file.
July 19, 2013 at 10:47 am
Thank you, there is none, just the ole error. it might help you to know the symptoms are the same when attaching mdf file. During troubleshooting i tried to upgrade, see if i can get in the db, i get denied access.
July 19, 2013 at 12:42 pm
No idea without an actual error message.
How are you attaching the DB? And, if you're restoring from backup, shouldn't that be restore not attach?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 19, 2013 at 12:52 pm
Here is the gist of it:
EurekaLog 6.0.20
Application:
------------------------------------------------------------------
1.1 Start Date : Fri, 19 Jul 2013 20:47:06 +0200
1.2 Name/Description: PMO.exe - (Profdoc Medical Office Client )
1.3 Version Number : 3.0.0.115
1.4 Parameters :
1.5 Compilation Date: Fri, 2 Oct 2009 15:04:13 +0200
1.6 Up Time : 15 seconds
Exception:
---------------------------------------------------------------
2.1 Date : Fri, 19 Jul 2013 20:47:22 +0200
2.2 Address : 00B7A090
2.3 Module Name : PMO.exe - (Profdoc Medical Office Client)
2.4 Module Version: 3.0.0.115
2.5 Type : EOleException
2.6 Message : OLE error 80040E14.
2.7 ID : F30E
2.8 Count : 1
2.9 Status : New
2.10 Note :
User:
-------------------------------------------------------
3.1 ID : Mias Louw
3.2 Name : pmoadmin
3.3 Email :
3.4 Company :
3.5 Privileges: SeShutdownPrivilege - OFF
SeChangeNotifyPrivilege - ON
SeUndockPrivilege - OFF
SeIncreaseWorkingSetPrivilege - OFF
SeTimeZonePrivilege - OFF
Active Controls:
------------------------------
4.1 Form Class : TfrmLogin
4.2 Form Text : PMO Login
4.3 Control Class: TButton
4.4 Control Text :
Call Stack Information:
----------------------------------------------------------------------------------
|Address |Module |Unit |Class |Procedure/Method |Line |
----------------------------------------------------------------------------------
|Running Thread: ID=1980; Priority=0; Class=; [Main] |
|--------------------------------------------------------------------------------|
|00B7A090|PMO.exe |uLogin.pas |TfrmLogin |btnOKClick |303[20]|
|755525A3|USER32.dll| | |NotifyWinEvent | |
|75547027|USER32.dll| | |GetWindowLongW | |
|75547033|USER32.dll| | |GetWindowLongW | |
|75550D48|USER32.dll| | |CallWindowProcW | |
|75550D32|USER32.dll| | |CallWindowProcW | |
|755562D0|USER32.dll| | |CallNextHookEx | |
|75556285|USER32.dll| | |CallNextHookEx | |
|75550F8C|USER32.dll| | |GetParent | |
|755496C0|USER32.dll| | |SendMessageW | |
|75550D48|USER32.dll| | |CallWindowProcW | |
|75550D32|USER32.dll| | |CallWindowProcW | |
|75556285|USER32.dll| | |CallNextHookEx | |
|75552ABC|USER32.dll| | |GetCapture | |
|75552AAC|USER32.dll| | |GetCapture | |
|75547885|USER32.dll| | |DispatchMessageW | |
|7554787B|USER32.dll| | |DispatchMessageW | |
|00CC3A5D|PMO.exe |uMainLogin.pas|TPDMainLogin|LogInShow |206[14]|
|00CC39CC|PMO.exe |uMainLogin.pas|TPDMainLogin|LogInShow |192[0] |
|00CC36C0|PMO.exe |uMainLogin.pas|TPDMainLogin|LogIn |119[14]|
|00CC35E0|PMO.exe |uMainLogin.pas|TPDMainLogin|LogIn |105[0] |
|00CC34BE|PMO.exe |uMainLogin.pas| |LogIn |67[9] |
|00CC3448|PMO.exe |uMainLogin.pas| |LogIn |58[0] |
|00D77130|PMO.exe |main.pas |TfrmMain |LogIn |1277[1]|
|00D770EC|PMO.exe |main.pas |TfrmMain |LogIn |1276[0]|
|00D760B7|PMO.exe |main.pas |TfrmMain |FormShow |747[6] |
|77632260|ntdll.dll | | |RtlLeaveCriticalSection | |
|776401EB|ntdll.dll | | |LdrGetProcedureAddressEx| |
|776401DD|ntdll.dll | | |LdrGetProcedureAddress | |
|75553181|USER32.dll| | |MonitorFromWindow | |
|7555319D|USER32.dll| | |MonitorFromWindow | |
|01559A00|PMO.exe |PMO.dpr | | |994[6] |
----------------------------------------------------------------------------------
July 19, 2013 at 1:01 pm
There's nothing in there of any use.
What, exactly are you doing? What is the exact outcome, with error messages.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 19, 2013 at 1:14 pm
Sorry about that. What am i doing? The app is used for storing clinical records. The data is kept in a sql database.On monday, that server started to give problems (looked like ha hdd failure, can also be motherboard), I made a full backup, thus, (DECLARE @PathName VARCHAR(1024)
SET @PathName = "C:\Profdoc Backups\PMOFullBackupFile" + CONVERT(VARCHAR,GETDATE(),112) + ".bak"
BACKUP DATABASE PMO
TO DISK = @PathName
WITH
INIT,
NAME = "DBBackup",
SKIP,
STATS = 10;
GO),
and then decommissioned the machine. The replacement came today, i re installed sql and my app. I can restore my .bak file without errors. I can attach the mdf files i copied off the old drive without errors. I can test connect with a datalink ok. But i cant get anything else out of the db. The app wont connect. I assume the mdf files is corrupt from the failure. Which of the tools are the best value, and does that sound like an option to you?
July 19, 2013 at 1:21 pm
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.
July 19, 2013 at 1:22 pm
You should try the last backup from before you started having problems, assuming you have a backup from before the problems started.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
July 19, 2013 at 1:26 pm
Can you connect to the database using other SSMS?
July 19, 2013 at 1:28 pm
The application is configured somehow to connect to the database. This could be a dialog or somewhere else, but it will eventually boil down to a connection string. In that connection string is specified the name of the server, database name, username and password. You need to find where the connection string is defined and probably make some adjustments to it and to the SQL Server.
1. The first step is to define the server as the new SQL Server instead of the old one.
2. The next step is to make sure the SQL login exists and the password is defined correctly.
3. In the database you restored from your backup, add a user that corresponds to the login.
4. Make sure the login has the appropriate permissions to the database to do whatever it is that the application does.
5. Then test the application.
July 19, 2013 at 1:32 pm
Thank you. Yes, the .ldf files attached as well, nicely. As to the user account, the very same account is used for the app authentication as well as sql, does that help? What i do know is that this process works almost every time, i never before had to remap users. The hardware failure, am i wrong to suspect it?
July 19, 2013 at 1:32 pm
neefjakkals (7/19/2013)
I can restore my .bak file without errors. I can attach the mdf files i copied off the old drive without errors.
Why restore then attach?
Surely you want one copy of the DB, not two, so you'd either restore the backup or attach the database files. What's the point of doing both?
I assume the mdf files is corrupt from the failure. Which of the tools are the best value, and does that sound like an option to you?
That's a huge, unproven assumption.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 19, 2013 at 2:54 pm
I restore as well as attach, i mentioned it to demonstrate that i have tried both ways available to me for recovering. The result is the same for both methods.
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply