trace info in Access 97

[latosca68]

I need to demostrate, in a forensic job, that I can change (insert,
update, delete) records in a table of an access database without
trace. How can I do
this ? I plan to make the queries or export to excel, make the changes
and import again. Does access logs this change.
Very important: Exists any kind of date/time that access manage
internaly. Something like MSysObects ? If exists how can I change?

Thanks for your time !!!
Alf

[MA]

"latosca68" <la*******@hotm ail.com> ha scritto nel messaggio
news:5a******** *************** ***@posting.goo gle.com...

I need to demostrate, in a forensic job, that I can change (insert,
update, delete) records in a table of an access database without
trace. How can I do
this ? I plan to make the queries or export to excel, make the changes
and import again. Does access logs this change.
Very important: Exists any kind of date/time that access manage
internaly. Something like MSysObects ? If exists how can I change?

Thanks for your time !!!
Alf

If the database has got any protection, it is available to any kind of
access
using excel, asp, vbs (also only linking it without importing).
That's because is very weak the way to log by tables tah access to them
So if you want to display is very easy.
In opposite, if you want to protect you have to use mdw, a rule of
permisses.
MAssimiliano

[Daven Thrice]

"latosca68" <la*******@hotm ail.com> wrote in message
news:5a******** *************** ***@posting.goo gle.com...

I need to demostrate, in a forensic job, that I can change (insert,
update, delete) records in a table of an access database without
trace. How can I do
this ? I plan to make the queries or export to excel, make the changes
and import again. Does access logs this change.
Very important: Exists any kind of date/time that access manage
internaly. Something like MSysObects ? If exists how can I change?

Thanks for your time !!!
Alf

There is nothing of which I'm aware that keeps track of changes unless one
specifically programs such functionality into the database. However, just
because I've not seen something like this in Access doesn't mean that it
doesn't exist. I suggest you contact microsoft directly with this question.

[Larry Linson]

"latosca68" <la*******@hotm ail.com> wrote in message
news:5a******** *************** ***@posting.goo gle.com...

I need to demostrate, in a forensic job, that I can change (insert,
update, delete) records in a table of an access database without
trace.

You cannot write to the MSys... tables. Those tables are, for the most part,
undocumented and, so is the structure of the Access database itself... MDB,
MDE, ADP, ADE, and DAP. Some people have delved deep and come to conclusions
about various aspects of the system tables, and of the structure of the
database. They can, at least, speculate on the subject.

Microsoft does not document them for a purpose -- the design of some of
those tables, and, I am sure, the design of the database itself, have
changed with every release of the product. If I were Microsoft, I, too would
want to avoid an implied commitment that the design would remain constant.

As I understand MSysObjects, it records the date of creation and update of
the design of Access objects, not changes to data.

The best answer I can give is that I do not know of any logging of data
changes that is documented by Microsoft. And, that would be a nice feature,
if it were available, for data recovery -- so it would seem that someone
would know about it if it existed. You would need someone who's looked into
the matter a lot deeper than most of us to get an answer.

If you can locate Peter Miller, you might discuss with him whether he could
serve as an expert witness -- he has an excellent reputation in data
recovery of corrupted Access databases. His website is
http://www.pksolutions.com.

Larry Linson
Microsoft Access MVP

[Peter Miller]

Larry Linson wrote:

You cannot write to the MSys... tables. Those tables are, for the most part,
undocumented and, so is the structure of the Access database itself... MDB,
MDE, ADP, ADE, and DAP. Some people have delved deep and come to conclusions
about various aspects of the system tables, and of the structure of the
database. They can, at least, speculate on the subject.
It depends on the version of Access involved. You used to be able to
edit and indeed spoof certain system tables, but assuming we're talking
about Access 2003 (which wasn't the version the original poster referred
to), things have improved somewhat. The spoofing is out.

While the structure of Access databases is not public, the structure of
table data is pretty easy to determine, and since the structure of the
system tables is easily viewed, its not very difficult to edit system
table data directly with a hex editor or custom program. The question
arises whether this is wise.
Microsoft does not document them for a purpose -- the design of some of
those tables, and, I am sure, the design of the database itself, have
changed with every release of the product. If I were Microsoft, I, too would
want to avoid an implied commitment that the design would remain constant.
I agree with the argument and rationale, but it is amazing how little
the file format has changed over time. Access 2.0 -> Access 95 was a
significant format shift. Changes since then have beeen much more
minor. In fact, changes in the file format for the last three versions
have been extremely minimal.
As I understand MSysObjects, it records the date of creation and update of
the design of Access objects, not changes to data.

The best answer I can give is that I do not know of any logging of data
changes that is documented by Microsoft. And, that would be a nice feature,
if it were available, for data recovery -- so it would seem that someone
would know about it if it existed. You would need someone who's looked into
the matter a lot deeper than most of us to get an answer.
There is no logging of data ativity that occurs in a jet database that
can be used reliably for recovery or auditing purposes, unless one is
using replication. If replication is used, a great deal of imformation
is indeed logged (as it must be for replication to be possible).
If you can locate Peter Miller, ...
Let me know if you locate him. I'd like to have a chat with the fellow too!
...you might discuss with him whether he could
serve as an expert witness -- he has an excellent reputation in data
recovery of corrupted Access databases.

I sense that the OP wasn't really looking for forensic information,
despite first appearances. I think what he was really after was a
simple transaction logging capability. For that, I'd suggest using
replication, provided the database is not large, doesn't have a lot of
data thrashing, and he can work his way through understanding the
replication related system tables. The idea would be not to synchronize
until one had checked the logs to ensure only valid activity. If the
file is large and/or a lot of data thrashing occurs, then the delayed
synchronisation will cause a lot of bloat. Why ever synchronize in such
a case? Because if the files aren't ever synced, the logs get unwieldy.

If the OP's question is assumed to actually relate to forensic analysis
of the db itself, then actions like exporting data to excel, modifying
it, and re-importing it would indeed leave a trace. But if the
'suspect' then created a new file, and imported all tables and data, it
would be easy to determine that a new file had been created, but
impossible to tell whether data changes had occured under a controlled
enviroment (ie, the intended f/e app) or by an outside program.

Peter Miller

[Salad]

latosca68 wrote:

I need to demostrate, in a forensic job, that I can change (insert,
update, delete) records in a table of an access database without
trace. How can I do
this ?
Open a table. Tables/Open. Change to your heart's delight. Delete
what you want. Nobody is going to stop you....unless user security has
been implemented.

In reality, you don't need forms or code to input, change, or delete
data. All you need is the ability to open a table. Forms and code are
used to provide ease of operation for the operator and to follow
business rules that have been defined by the system requirements.

FoxPro and Access are easy to change data without using normal input
mechanisms. I'll assume the same holds true with most database
management systems...if you have access to the tables you have access to
change data.

I plan to make the queries or export to excel, make the changes and import again. Does access logs this change.
You need to build in rules. A computer, in most cases, is pretty dumb.
It doesn't know right from wrong (unless told) or whether an action
should be rejected or allowed (unless told).
Very important: Exists any kind of date/time that access manage
internaly. Something like MSysObects ? If exists how can I change?
What would be required is that if you delete rows to a table Access
triggers an action to store/copy the deleted rows to a temp/work table.
Same way with adds and mods.

One could write code that anytime anything is changed, it gets written
somewhere. But that would require going through a form or code module.
If one has access to the table...no way.

Now there is database bloat...and that is removed when you compact the
database. I suppose you could determine what records were deleted prior
to compacting if you knew what to look for..and it would probably have
to be done from an external program. It would not tell you who did the
changes tho.

Data is data. And data is stored to be retrieved, viewed, and in many
cases modified. One has to trust the staff using an application is
trustworthy. The best thing to do is have a good backup system in
place. In that case, you could compare today's data to a prior day's
data and determine what has been changed. However, if you don't have
the code to tell the table to store the name of the person that changed
the data and a date/time stamp then that will not be inserted and you
have noone to point fingers at.
Thanks for your time !!!
Alf

[David W. Fenton]

Peter Miller <pm*****@pksolu tions.com> wrote in
news:nn******** **********@news-server.bigpond. net.au:

I think what he was really after was a
simple transaction logging capability. For that, I'd suggest
using replication, provided the database is not large, doesn't
have a lot of data thrashing, and he can work his way through
understanding the replication related system tables. The idea
would be not to synchronize until one had checked the logs to
ensure only valid activity. If the file is large and/or a lot of
data thrashing occurs, then the delayed synchronisation will cause
a lot of bloat. Why ever synchronize in such a case? Because if
the files aren't ever synced, the logs get unwieldy.

I would strongly recommend against attempting to use replication for
this purpose. That was *not* what it was designed for, and it's
likely to lead you to grief.

Secondly, the replication tables, like the system tables, are not
really documented, so you'd have to spend a lot of time figuring out
what is in them.

Third, they don't really record a log of edits, just the *last* edit
for the replica you're examining. So, you can't really get logging
of data changes via replication anyway, so why bother to try it?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc