Linked Table-Embed Password

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am linking tables in Access 2003 to AS400 via odbc setup. Originally
everyone used their individual AS400 login/password when prompted on the
Access database open, but now we have a secure common login/password. How
can I embed the login/password into the table links now that the links are
already in place. The only way I have found is to re-link the table, a
difficult and not happy chore when Access seems to lose every relationship in
the process. During the initial link wizard process is a box asking to "save
password" but I can't find where to change it or add it except at the initial
link table time. Help Appreciated. Linda
 
LindaD wrote:
(snip)
The only way I have found is to re-link the table, a
difficult and not happy chore when Access seems to lose every relationship in
the process.
Click to expand...

The relationships should be defined in the back end (containing the
tables), not the front end (containing the links to the tables).

HTH,
TC
 
Hi, Linda.
now we have a secure common login/password.
Click to expand...

If everyone is sharing the same login ID and password, then it is not
secure. And if the login ID and password are stored in an Access database,
then anyone on your PC network can use them to log into the AS/400 computer,
including hackers.
How
can I embed the login/password into the table links now that the links are
already in place.
Click to expand...

You can't.
The only way I have found is to re-link the table,
Click to expand...

This is the correct procedure, since the new link will store information
about the table structure, connection information (including user ID and
password), and usage statistics for Jet to use the table in the most
efficient way when creating query plans.
a
difficult and not happy chore when Access seems to lose every relationship
in
the process.
Click to expand...

Then you'll be happy to hear about this time saver: Don't bother assigning
relationships to remote tables from the front end. No relational database
can enforce relationships in remote tables, only in tables in the current
database. Those relationships _must_ be established in the back end, i.e.,
in the single database that contains the tables on the AS/400. If the
database on the AS/400 isn't a relational database or the tables are in
multiple files, then no enforceable relationship can be established on those
tables.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
 
As to the security issue you bring up, the "common"
login/password setup on the IBM400 secure, read-only.
It's all in how the Administrator of the main system sets
up the user. When everyone used their own login, it was
then not secure at all, allowing write. The main reason
for the one login was the security. The administrator of
that system has setup view of only 6 table with this
login. It is a common way to "secure" Access getting into
main databases, something not to many people bother with,
not understanding data can be written from Access to the
other database if the login is not set up with proper
security. Sorry, I disagree with you on this one.
 
Sorry, your response makes so sense at all, back end table
versus front end links?? never heard of that....everyone
says to re-link the table. If you use the Link Table
manager on the current table, there is no option to save
the password. The only way to re-link a table is to
delete it and do a new table and when linking, hit the
save password box. Since I did not set up these database,
who know what someone else did to the relationships but to
delete a table, then start over with a new table is a
mess. Is this the only way to do this?
 
What TC's trying to say is that if you're using tables from another source
(or even from another Access database), any relationships that are defined
must exist in the back-end. Any relationships you might have put in the
front-end don't actually do anything.
 
Hi, Linda.
When everyone used their own login, it was
then not secure at all, allowing write. The main reason
for the one login was the security.
Click to expand...

Don't confuse data security issues with data integrity issues. If a
legitimate user writes data or updates data in the table unintentionally,
this compromises the integrity of the data. The consequences of a loss of
data integrity are that reports may come up with incorrect or inconsistent
information.

This is negligence, but is rarely defined as a criminal act.

If an unauthorized user views or copies the data, this compromises the
security of the data. If an unauthorized user changes the data, this
compromises the security, as well the integrity, of the data. The
consequences of a loss of security are that industrial espionage, theft
(especially identity theft), fraud, or blackmail may occur.

These are considered a criminal acts.

Big difference.
It is a common way to "secure" Access getting into
main databases, something not to many people bother with,
not understanding data can be written from Access to the
other database if the login is not set up with proper
security.
Click to expand...

It may be common, but it's not secure. If you lock the door and put the key
under that doormat or otherwise leave the key in plain sight for everyone to
use, you cannot claim this door is "secure."

A better way to prevent legitimate users from accidently writing to remote
tables is to ensure that the recordset is non-updateable, something that not
too many people bother with because they don't understand that tables don't
have to be linked with the Linked Table Manager in order to view the data in
these remote tables.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
 
Back
Top