need Password Hack for Earlier Version Of Access DB

[Mike]

Hi, we have an Access DB we can access that was created by someone who no
longer works us.
I believe it's Access 95 or the next version of Access. Is there a
shareware or freeware Access DB
out there that's works.

Thanks,

Mike'

 

[Larry Linson]

Hi, we have an Access DB we can access that was created by someone who no
longer works us.

You do know that everybody who wants to break security on a purchased
database sings that same song, don't you? How would anyone here know the
difference between you and them? But, see below...

I believe it's Access 95 or the next version of Access. Is there a
shareware or freeware Access DB
out there that's works.

Surely. The web is full of database cracks. For Access 97, there's a
significantly good one that's free and doesn't even require you have the
workgroup file. It may or may not still be downloadable. For current
versions, for user/group level security, you'll likely have to pay. Wait,
you didn't expect me to do all your work for you, did you? HINT: The
author's name is Sergey or Sergei and "Google is your friend." (Just for
your information, that author quit doing cracks soon thereafter... the ROI
was not worth the hassle.)

Larry Linson
Microsoft Access MVP

 

[Chris Syn]

I personally believe that US Americans are unable to do so because some
people out there in our nation don't have maps and I believe that our
education like such as South Africa and the Iraq everywhere like, such as
and I believe that they should, our education over here in the US should
help the US or should help South Africa and should help the Iraq and the
Asian countries so we will be able to build up our future.

 

[Alfred]

Hi, we have an Access DB we can access that was created by someone who no
longer works us.
I believe it's Access 95 or the next version of Access. Is there a
shareware or freeware Access DB
out there that's works.

Google on 'access passwords' gets about 24 million hits.
Never heard of a freeware access password recovery utility.

 

[Tom Ventouris]

I found a good one that does the job with Browse and a click.
I doubt I am the only person who has this, some advice or suggestions on the
implications from those in the know before I post?

 

[James A. Fortune]

I found a good one that does the job with Browse and a click.
I doubt I am the only person who has this, some advice or suggestions on the
implications from those in the know before I post?

Please don't post it. Maybe have the OP email the file to you and send
it back with a new password if they can convince you they're legit.

There is enough information in the NG's for programmers to do it. I'd
rather not have everyone be able to do it. I have to use the lowest
common denominator for back ends. For a little while longer that means
A97. If I put a password on a back end, I'd like for there to be a
reasonable chance that average office workers won't be able to break it.

See:

http://groups.google.com/group/comp.databases.ms-access/msg/e80cea665762a8b4

James A. Fortune
[email protected]

 

[Tom Ventouris]

Thanks, just checking.
I have no intention of posting such, however I am curious about how one
would protect the BE with a password. Don't the linked users need the
password to work on it through the FE?

I have only ever used passwords to keep general office staff out of the FE,
and have never found a way to keep them out of the BE. On occasion I have
created a start up form and disabled the shift key, but often leave the BE
open in case I need to add fields by "correspondence". They always think of
something to add after the initial deployment!

 

[James A. Fortune]

Thanks, just checking.
I have no intention of posting such, however I am curious about how one
would protect the BE with a password. Don't the linked users need the
password to work on it through the FE?

Of course. I haven't tried putting the database password in a
connection string yet (I'm still not using MDE's much yet but that's
changing soon). Suppose someone wants to create a link to a table in a
back end. They have to supply the database password to create that
link. With the software you mention, they can find out that password.
You're correct that the situation is rare. I have only one back end
with a database password.

James A. Fortune
[email protected]

 

[kevin wilcox]

I'm actually trying to do the opposite - I need to password protect a back end but can't figure out the VB to then make this accessible from the FE, i.e. the connection string stuff - always managed to duck using connection strings so far! Can anyone help with a sample please?

EggHeadCafe - .NET Developer Portal of Choice
http://www.eggheadcafe.com

 

[James A. Fortune]

I'm actually trying to do the opposite - I need to password protect a back end but can't figure out the VB to then make this accessible from the FE, i.e. the connection string stuff - always managed to duck using connection strings so far! Can anyone help with a sample please?

EggHeadCafe - .NET Developer Portal of Choice
http://www.eggheadcafe.com

There are many examples of connection strings in the newsgroups.

Search for: connection string database password

in comp.databases.ms-access or in microsoft.public.access

Be sure to consider the possibility of using the MSysConf table.

From A97 Help:

Use the MSysConf table with linked SQL databases

If you are administering an SQL database that uses Microsoft Access as a
front end, you can create a table in your SQL database named MSysConf to
help you control communication between the two applications. The
MSysConf table has two potential functions:

· It can disable the feature that enables users to save the logon ID and
password for a linked SQL database in the Microsoft Access front end.
· It can optimize how Microsoft Access performs background population of
records during idle time by setting the number of rows of data that are
retrieved at one time and the number of seconds of delay between each
retrieval. Microsoft Access uses a default of 100 records returned every
10 seconds if you don't create the MSysConf table.

....

Config nValue Meaning
101 0 Don't allow local storage of the logon ID and password in linked
tables.
101 1 Allow local storage of the logon ID and password in linked tables.
102 D D is the delay in seconds between each retrieval.
103 N N is the number of rows retrieved.
Notes

· Setting a higher delay time decreases network traffic, but increases
the amount of time that read-locks are left on data (if the server uses
read-locks).
· If you create an MSysConf table, it must be set up properly or you
will not be able to connect to the SQL database table at all.

From "Jet Database Engine Programmer's Guide" (Jet 3.5):

The MSysConf table is a special table that you create in your remote
database. You can use it to:

· Prevent users from storing the Login ID and password locally for a
linked SQL table.

· Set the number of records that are retrieved at one time.

· Set the number of seconds of delay between each retrieval.

....

The MSysConf table currently recognizes three configuration settings.
These settings are activated by adding a record to the table for each
setting. Currently, only the Config and nValue fields are used; the
chValue and Comments fields are reserved for future use and are ignored
in this release.

BTW, I would be interested in hearing about experiences from anyone who
has done any significant tweaking of those settings.

James A. Fortune
[email protected]

 

[goode2fox]

use the tom website

Thanks, just checking.
I have no intention of posting such, however I am curious about how one
would protect the BE with a password. Don't the linked users need the
password to work on it through the FE?

I have only ever used passwords to keep general office staff out of the FE,
and have never found a way to keep them out of the BE. On occasion I have
created a start up form and disabled the shift key, but often leave the BE
open in case I need to add fields by "correspondence". They always think of
something to add after the initial deployment!