Question : Check to see if a column name in a linked table has changed

I am building an application that uses several linked tables.  However, one of the users is a cowboy and will change the name of columns and not tell anyone.  Is there anyway to check the names of columns in a linked table.  Otherwise, a dialog box appears with the name of the missing column asking for a parameter and the user won't know what this means.

Answer : Check to see if a column name in a linked table has changed

Properly lock down your database so your cowboy can't change the column names. Only allow your users access to form and reports and then they can't make design changes. You can do this in Tools, Startup options.

Here is a short discussion of MS Access security.

To secure the frontend (the db with the forms, reports, code, etc.), you have seven levels of security, lowest to highest in security level also easiest to hardest (you can use any combination of them):

1: Goto tools, startup.  Uncheck all the check boxes including the one after clicking advanced in W2k.  Downside: The shift bypass can be used to open the db

2: Disable the shift bypass.  The easiest way to do this is with a utility such as: Access Property Editor at: http://www.jamiessoftware.tk  Downside: Can be easily enabled. However if you add code to a module which deletes the database if the shift bypass is disabled and call the sub from every on open event of every form and report, you can make life a little more complicated for someone trying to bypass the shift bypass.  This is explained in //www.thenelson.name, Shift Bypass Functions.

3: Convert the Front End to a mde file (tools, database utilities, make mde file) which removes the readable code and design information. Be sure you keep a copy of the mdb file.  Downside: There are programs available that can back engineer the missing design info and code.
 
4: Build your own login/security system.  Here is a sample database to show you how (or just cut and paste): http://www.thenelson.name/,  Simplified Login.  Downside: Easily circumvented by shift bypass, opening with another database or just looking at the security tables if they are not encrypted.

5: Set passwords for the front end (the part with forms, etc) and backend with tools>security>set passwords.  If you don't want your users to have to put in the user name and password, you would then put the following in the shortcut to start your database:
msaccess /User /Pwd
Downside: a: the user name and password is easy to read from the shortcut. b: there are programs readily available starting at about $20 which will parse out the user name and password.

6: Use msaccess user level security (ULS).  A great reference: http://support.microsoft.com/default.aspx?scid=%2Fsupport%2Faccess%2Fcontent%2Fsecfaq.asp
Downside: a: same as 6a,  b: a huge jump in complexity,  c: there are programs readily available starting at about $100 which will parse out the user names and passwords.

7: Write the Front End in a compiled language and compile an exe file. Downside: same as 7b


To secure the backend (the db with the data), you have five levels of security, lowest to highest in security level also easiest to hardest (you can use any combination of them):

1: Create a macro in the backend with the name of autoexec.  A macro with that name will run whenever someone tries to open the backend directly.  Have the macro create a msgbox with something like "You bad, bad boy!" and quit.  Downside: someone can easily access the data from another db.

2: Set passwords for the front end (the part with forms, etc) and backend with tools>security>set passwords.  If you don't want your users to have to put in the user name and password, you would then put the following in the shortcut to start your database:
msaccess /User /Pwd
Downside: there are programs readily available starting at about $20 which will parse out the user name and password.

3: Encrypt the backend with tools > security > encrypt.  Downside: Since Access encryption does not use a key, anyone with Access and the user name/password from 2 above can decrypt it.

4: Use msaccess user level security (ULS).  Downside: a: a huge jump in complexity,  b: there are programs readily available starting at about $100 which will parse out the user names and passwords.  

5: Create your own BE encryption scheme or use an encryption addin.  Downside: a: same as 4a, b: if you lose your encryption key or the backend gets corrupted and you don't have backups, you are screwed big time.
http://support.microsoft.com/default.aspx?scid=KB;en-us;q165009
http://www.netlib.com/encryption-software.shtml
Random Solutions  
 
programming4us programming4us