G
Guest
If Access contains metadata, is it possible that information deleted from an
Access database could be recovered? If so, how hard is it to do this?
Access database could be recovered? If so, how hard is it to do this?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
G
Guest
Hi.
An Access database file contains some metadata, but it's not as extensive as
you'll find in client/server databases. Recovery of deleted information from
an Access database is severely limited. It's usually best, and cheapest, to
restore from a recent backup when these types of boo-boos are made.
It depends upon what was deleted. If you deleted an object in the Database
Window, then select the tab for that type of object and press <CTRL><Z> to
"undo" the operation. If that was the most recent operation in that tab, it
will "undo" the object's deletion, but only for one object, so if you deleted
more than one object, you are probably SOL.
If you deleted one or more tables and you haven't closed the database since
they were deleted, and you haven't compacted the database, and the tables
were deleted in the GUI (not by using SQL, VBA code or a macro), then please
see the following Web page for a way to recover them:
http://support.microsoft.com/kb/209874
If you deleted records, then they've been "marked for deletion" by Jet, so
Jet overwrites parts of these records while doing its housekeeping, which
makes these records mostly corrupted data. Because of this, recovery
services can recover as much as 5% of deleted records, so it's usually not
worth the expense. It's best to restore from a recent backup. You _do_ have
a recent backup, don't you?
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info.
If Access contains metadata, is it possible that information
deleted from an Access database could be recovered?
An Access database file contains some metadata, but it's not as extensive as
you'll find in client/server databases. Recovery of deleted information from
an Access database is severely limited. It's usually best, and cheapest, to
restore from a recent backup when these types of boo-boos are made.
If so, how hard is it to do this?
It depends upon what was deleted. If you deleted an object in the Database
Window, then select the tab for that type of object and press <CTRL><Z> to
"undo" the operation. If that was the most recent operation in that tab, it
will "undo" the object's deletion, but only for one object, so if you deleted
more than one object, you are probably SOL.
If you deleted one or more tables and you haven't closed the database since
they were deleted, and you haven't compacted the database, and the tables
were deleted in the GUI (not by using SQL, VBA code or a macro), then please
see the following Web page for a way to recover them:
http://support.microsoft.com/kb/209874
If you deleted records, then they've been "marked for deletion" by Jet, so
Jet overwrites parts of these records while doing its housekeeping, which
makes these records mostly corrupted data. Because of this, recovery
services can recover as much as 5% of deleted records, so it's usually not
worth the expense. It's best to restore from a recent backup. You _do_ have
a recent backup, don't you?
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info.
G
Guest
Thanks for the response. I was actually asking the question about recovering
data from a security standpoint. I want to ensure that certain information in
an Access file cannot be recovered when the file is given to an outside
party.
Let's say a copy is made of an Access file which is later redacted to remove
information in column B (for example) before being turned over to another
party. Would this COMPLETELY remove the data? The data in question in highly
sensitive and must not be recoverable by an outside party.
Thanks,
Techno
data from a security standpoint. I want to ensure that certain information in
an Access file cannot be recovered when the file is given to an outside
party.
Let's say a copy is made of an Access file which is later redacted to remove
information in column B (for example) before being turned over to another
party. Would this COMPLETELY remove the data? The data in question in highly
sensitive and must not be recoverable by an outside party.
Thanks,
Techno
J
John Vinson
Let's say a copy is made of an Access file which is later redacted to remove
information in column B (for example) before being turned over to another
party. Would this COMPLETELY remove the data? The data in question in highly
sensitive and must not be recoverable by an outside party.
I would not count on it, and - as much as I love working with Access
- I'd be very cautious about using Access for such sensitive data in
the first place.
Compacting the database will recover the space, but it is not designed
to seek out and specifically overwrite all such data. A binary sniffer
(either on the .mdb file or on the hard disk where it was stored
before being compacted) could very likely extract information that has
been nominally "deleted".
John W. Vinson[MVP]
G
Guest
Hi.
If you need to safeguard the data, then don't store it in Access. Store it
in a client/server database, such as SQL Server or Oracle. Both Microsoft
and Oracle offer free versions of their latest client/server databases, SQL
Server 2005 Express and Oracle 10g Express, respectively, so you wouldn't
even have to worry about the added expense of licensing.
No. It wouldn't. Say you delete the AnnualSalary column from the table,
because you don't want the outside party to know how much they'd have to
offer to draw your best employees away from your company. If you open the
table afterwards, you'd see that there is no longer an AnnualSalary column,
so all of the data in that column appears to be gone. However, Jet never
deletes columns from a table. All new records will store a NULL value for
this column but the previous records will still contain the data that was in
the AnnualSalary column at the time of deletion. This data can be read with
a Hex editor. Even if you compact the database, the data still remains in
the deleted column of this table.
Say you ran an UPDATE query on the AnnualSalary column to set all values to
NULL. If you open the table afterwards, you'd see that there are no longer
any values in the AnnualSalary column. However, the file may contain this
deleted data, anyway, which can be read with a Hex editor. Any records which
have previously been deleted are only "marked for deletion," so they aren't
actually zeroed out. These previously "deleted" records, if not already
overwritten, would still contain values in the AnnualSalary column after the
UPDATE query sets the rest of the visible records to NULL. In addition, if
there's an index on this field, then the index's data leaf pages could
contain these values, albeit the corresponding index records would also be
marked for deletion.
Once the database is compacted, the records will be reordered so that they
occupy contiguous space within each data page, and the records that had been
marked for deletion will not be carried over to the new file, but it's
possible to find the rows for these "deleted" records inside the "slack
space" that each data page contains in the new file with a Hex editor.
(Note: From testing, it's not clear whether or not these "deleted" records
were from a previous compaction that the new file is overwriting.) If these
"deleted" records are in the slack space, then they'll remain there until Jet
eventually overwrites them with new records. Same thing with the index
records.
The bottom line is that you can't guarantee that at least some of the data
won't remain in the file after it appears that you've successfully removed it.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info.
The data in question in highly
sensitive and must not be recoverable by an outside party.
If you need to safeguard the data, then don't store it in Access. Store it
in a client/server database, such as SQL Server or Oracle. Both Microsoft
and Oracle offer free versions of their latest client/server databases, SQL
Server 2005 Express and Oracle 10g Express, respectively, so you wouldn't
even have to worry about the added expense of licensing.
Let's say a copy is made of an Access file which is later redacted to remove
information in column B (for example) before being turned over to another
party. Would this COMPLETELY remove the data?
No. It wouldn't. Say you delete the AnnualSalary column from the table,
because you don't want the outside party to know how much they'd have to
offer to draw your best employees away from your company. If you open the
table afterwards, you'd see that there is no longer an AnnualSalary column,
so all of the data in that column appears to be gone. However, Jet never
deletes columns from a table. All new records will store a NULL value for
this column but the previous records will still contain the data that was in
the AnnualSalary column at the time of deletion. This data can be read with
a Hex editor. Even if you compact the database, the data still remains in
the deleted column of this table.
Say you ran an UPDATE query on the AnnualSalary column to set all values to
NULL. If you open the table afterwards, you'd see that there are no longer
any values in the AnnualSalary column. However, the file may contain this
deleted data, anyway, which can be read with a Hex editor. Any records which
have previously been deleted are only "marked for deletion," so they aren't
actually zeroed out. These previously "deleted" records, if not already
overwritten, would still contain values in the AnnualSalary column after the
UPDATE query sets the rest of the visible records to NULL. In addition, if
there's an index on this field, then the index's data leaf pages could
contain these values, albeit the corresponding index records would also be
marked for deletion.
Once the database is compacted, the records will be reordered so that they
occupy contiguous space within each data page, and the records that had been
marked for deletion will not be carried over to the new file, but it's
possible to find the rows for these "deleted" records inside the "slack
space" that each data page contains in the new file with a Hex editor.
(Note: From testing, it's not clear whether or not these "deleted" records
were from a previous compaction that the new file is overwriting.) If these
"deleted" records are in the slack space, then they'll remain there until Jet
eventually overwrites them with new records. Same thing with the index
records.
The bottom line is that you can't guarantee that at least some of the data
won't remain in the file after it appears that you've successfully removed it.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info.
G
Guest
Hi.
If you need to safeguard the data, then don't store it in Access. Store it
in a client/server database, such as SQL Server or Oracle. Both Microsoft
and Oracle offer free versions of their latest client/server databases, SQL
Server 2005 Express and Oracle 10g Express, respectively, so you wouldn't
even have to worry about the added expense of licensing.
No. It wouldn't. Say you delete the AnnualSalary column from the table,
because you don't want the outside party to know how much they'd have to
offer to draw your best employees away from your company. If you open the
table afterwards, you'd see that there is no longer an AnnualSalary column,
so all of the data in that column appears to be gone. However, Jet never
deletes columns from a table. All new records will store a NULL value for
this column but the previous records will still contain the data that was in
the AnnualSalary column at the time of deletion. This data can be read with
a Hex editor. Even if you compact the database, the data still remains in
the deleted column of this table.
Say you ran an UPDATE query on the AnnualSalary column to set all values to
NULL. If you open the table afterwards, you'd see that there are no longer
any values in the AnnualSalary column. However, the file may contain this
deleted data, anyway, which can be read with a Hex editor. Any records which
have previously been deleted are only "marked for deletion," so they aren't
actually zeroed out. These previously "deleted" records, if not already
overwritten, would still contain values in the AnnualSalary column after the
UPDATE query sets the rest of the visible records to NULL. In addition, if
there's an index on this field, then the index's data leaf pages could
contain these values, albeit the corresponding index records would also be
marked for deletion.
Once the database is compacted, the records will be reordered so that they
occupy contiguous space within each data page, and the records that had been
marked for deletion will not be carried over to the new file, but it's
possible to find the rows for these "deleted" records inside the "slack
space" that each data page contains in the new file with a Hex editor.
(Note: From testing, it's not clear whether or not these "deleted" records
were from a previous compaction that the new file is overwriting.) If these
"deleted" records are in the slack space, then they'll remain there until Jet
eventually overwrites them with new records. Same thing with the index
records.
The bottom line is that you can't guarantee that at least some of the data
won't remain in the file after it appears that you've successfully removed it.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info.
The data in question in highly
sensitive and must not be recoverable by an outside party.
If you need to safeguard the data, then don't store it in Access. Store it
in a client/server database, such as SQL Server or Oracle. Both Microsoft
and Oracle offer free versions of their latest client/server databases, SQL
Server 2005 Express and Oracle 10g Express, respectively, so you wouldn't
even have to worry about the added expense of licensing.
Let's say a copy is made of an Access file which is later redacted to remove
information in column B (for example) before being turned over to another
party. Would this COMPLETELY remove the data?
No. It wouldn't. Say you delete the AnnualSalary column from the table,
because you don't want the outside party to know how much they'd have to
offer to draw your best employees away from your company. If you open the
table afterwards, you'd see that there is no longer an AnnualSalary column,
so all of the data in that column appears to be gone. However, Jet never
deletes columns from a table. All new records will store a NULL value for
this column but the previous records will still contain the data that was in
the AnnualSalary column at the time of deletion. This data can be read with
a Hex editor. Even if you compact the database, the data still remains in
the deleted column of this table.
Say you ran an UPDATE query on the AnnualSalary column to set all values to
NULL. If you open the table afterwards, you'd see that there are no longer
any values in the AnnualSalary column. However, the file may contain this
deleted data, anyway, which can be read with a Hex editor. Any records which
have previously been deleted are only "marked for deletion," so they aren't
actually zeroed out. These previously "deleted" records, if not already
overwritten, would still contain values in the AnnualSalary column after the
UPDATE query sets the rest of the visible records to NULL. In addition, if
there's an index on this field, then the index's data leaf pages could
contain these values, albeit the corresponding index records would also be
marked for deletion.
Once the database is compacted, the records will be reordered so that they
occupy contiguous space within each data page, and the records that had been
marked for deletion will not be carried over to the new file, but it's
possible to find the rows for these "deleted" records inside the "slack
space" that each data page contains in the new file with a Hex editor.
(Note: From testing, it's not clear whether or not these "deleted" records
were from a previous compaction that the new file is overwriting.) If these
"deleted" records are in the slack space, then they'll remain there until Jet
eventually overwrites them with new records. Same thing with the index
records.
The bottom line is that you can't guarantee that at least some of the data
won't remain in the file after it appears that you've successfully removed it.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.