I have a database file (that I have current backups of) fail to open with error 3022. All of the tables used are remote, SQL Server or access. My backup database file can open with no issues and we have no data lost. I tried to do a compact and repair on the file remotely using application.CompactRepair but that fails giving me error 31523. I tried using the command line and opening the file with the /compact switch, but that also failed.
Why would I be getting the 3022 error just opening the database file?
It seems that there was a network error while accessing the database file on a network share. That caused internal corruption in a way that I don't really understand, and can not repair with a compact and repair. The good news is, a query that specifies the database file as a source CAN access data from any tables said database has, the bad news is, if there are any objects like forms, reports, or code modules that you do not have a backup of, you are out of luck.
The moral of the story? Keep good backups and don't use local tables.
Related
I am suddenly receiving the below error message when attempting to compact and repair my access databases. Clicking ok on the error message results in original .accdb file being deleted and an .mdb being saved out. When entering the database I'm not in read only so I'm confused on what is happening.
Microsoft Access can't delete accdb file path after compacting it. The compacted database has been named new mdb file path
When I have a database corruption that is not easily solved, I generally create a new, blank database, then import everything from the faulty db.
It's reasonably fast, and you can actually see and take note of which object fails to import. You can then import the problematic object(s) from your last backup.
Also: do all that stuff on a LOCAL drive, not a network drive. Network drives often are the culprit.
I have an error with Xampp where it will not connect to my database. I have had this error several times in the past and no solutions have helped. I find that uninstalling and reinstalling ends up being the fastest method, however, by doing so I lose my database tables. As I have no access to the default export and import functions, I was wondering how I transfer the tables across.
Last time, I copied and pasted these files into the same directory when I reinstalled Xampp and the tables transferred but the data within did not. The tables had also lost some functionality as well.
If anyone has any methods to do this I will greatly appreciate it.
The best way to backup and restore your data is to dump the database to an SQL file. You can use the provided mysqldump tool for that, which is the best tool for the job.
Copying the entire MySQL "datadir" (which is probably one level up from the screenshot you've posted) and completely replacing one of your new stopped MySQL instance will probably work, but is not reliable and is not supported. Since there are other files (such as ibdata1) that handle the overall health and functioning of the entire MySQL instance, you can't only copy over individual database directories. Furthermore, you should only do this when the original and replacement MySQL servers/daemons/services are completely stopped because otherwise there are file corruption or concurrency issues.
Since you're running the server on your own computer, you should grant yourself sufficient access to be able to use mysqldump and use that regularly as a backup, since file-level backups of the data directory are not reliable.
I have a very large sql database that I was trying to switch over to a different computer. When starting sql on that other computer I got the error of
"service did not respond in a timely fashion".
So I switched the database back to my original computer, got the same error, deleted the ibdata and ib log files and .frm files. Same error.
I assume it's not waiting long enough to read the tables but don't know how to correct this. I read the fixes about VIA protocol but this is not a networked drive, its just connected via usb.
My main concern is that my database will be lost. Please reassure me that if i have the ibd file that my database is still safe.
I'm thinking I should reimport my ibd file using this method.
https://dev.mysql.com/doc/refman/5.6/en/innodb-migration.html#copy-tables-cold-backup
Correct?
Edit. I was able to reimport my data using this method. Just had to remake my schema similar enough to the original.
if you copy .frm files of mysql database to another server, you will be able to get the table structure. This means if someone get access to my server and copy .frm files the person will see my table structure when it is attached to his server. this obviously makes it unsecure. How do you prevent that from happening?
hiding the path does not solve the problem because the .frm file can be searched.
Is there a mechanism that will generate an error when the file is attached to a different server?
Your schema is not that important for security. Getting the table structure is only a security threat if you have other security problems in your code. What you should be really worried about is how someone got to your .frm files in the first place because that means they have access to your database server, and hence possibly all your database data. The schema is the least of your problems.
When people have access to files on your server the battle is already lost. They should not get that far in the first place. Therefore make sure you secure your SSH server, file servers etc.
This is a bit of a problem! I had shut down an instance on SQL Server and today I started it up again.
However one of the databases (the main one that I work with) is not accessible.
When I attempt to expand the database in SSMS to view tables, I get the error:
The database is not accessible. (objectExplorer)
I found this article which looked like it may solve the issue (assuming that it is a permissions issue) but that did not work either: http://sqlserver-help.com/2012/02/08/help-i-lost-sa-password-and-no-one-has-system-administrator-sysadmin-permission-what-should-i-do/
In the SQL Server error logs I am seeing:
FCB:Open failed: Could not open file E:\\.mdf for file number 1. OS error: 32 The process cannot access the file because it is being used by another process.
There is plenty disk space and so I am stuck with what the issue is.
I do have a recent backup so I'm not overly concerned about losing this database but still - I would like to be able to recover it if at all possible.,
Any help appreciated.
UPDATE - I used ProcessExplorer which showed that sqlservr.exe is using the file EVEN AFTER STOPPING THE SERVICE!
When I attempt to detach the database I get an error about Primary files do not match or that log file is from different database. Confusing!
Thanks.
No idea what the issue was still - but it was resolved by rebuilding the log file.