Results 1 to 2 of 2
  1. #1
    Join Date
    Jul 2004
    Posts
    125

    Unanswered: Protecting crucial data

    I have a single user DAO .MDE database application
    where the calculations rely on data defined
    by an external authority and it must not be altered.

    To protect the data from accidental alteration,
    it is my intention to imbed the data as text lines
    in a module.

    When the database is opened, a procedure empties
    the data table and appends the contents of the text
    in the module into the table.

    There data consists of 62 records (rows) of 23 columns.
    The data changes very rarely, and change would
    involve simple text editing.

    I am sure that others have come upon a similar
    challenge, and my question is if there are other
    methods to protect crucial data.

    Thanks for any suggestions

  2. #2
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    I'm not quite sure what you mean here...
    "it is my intention to imbed the data as text lines
    in a module"

    but I'm guessing this is going to be an Access table which you need to protect in some way. A couple of things I would do to protect an Access table...
    1. If possible, make it a SQL Server table and link it into Access. That way I could do tranlog backups of the table every hour, restoring it at any point in time if I had to. I could also see transactions better.
    2. Embed read/write permissions on the table either via MSAccess Security (an MDW file) or via SQL Server.
    3. Make my front-end an mde so if the code bombs at some point, users can't easily get into the code or into the tables.
    4. Do my best to have the most control over the forms to not let users close them to the tables/edit data (an example is here: http://www.dbforums.com/showpost.php...0&postcount=20 where a user can't easily close the forms.)
    5. Perhaps an audit-log type table either simple or detailed if the changes are critical. A simple one would entail fields like DateModified and ModifiedBy in the main data table (along with DateEntered and EnteredBy). The usernames LoginID's are gotten as shown in the example for ModifiedBy and EnteredBy fields.
    6. Lock the form with an Edit button where only users in the dbo_AdminTable (as in the example again) have permissions to edit data. The form might be unbound with a function to read/write data which is what I think you're saying above.
    7. Linked tables to either another Access or SQL Server.
    8. I could also do some little tricks like Hide the Tables in the Startup or right-clicking on a specific table and change it's Hidden Attribute to True. Hidden Attribute works like Windows Explorer.

    You have to look at in the way that if a user "somehow" closes your form(s) and gets into the tables (which they should know better not to), then without security on the table itself, all bet's are off and the user can do what they want to uncontrolled by any form limitations. A lot of secretarial/data entry jobs around here now require employees to know how to create and edit Access tables so some users may "think" that's one way they can enter data. I know a few friends of mine who are vp assistants and they all are required to know how to do this but oddly enough, a lot of time was not spent on form design or necessity to enter data via a form. I don't know who trained them but they responded "why should I enter data in a form when it's easier to do it in a table?" So somehow this philosophy does exist somewhere.
    Last edited by pkstormy; 08-12-07 at 17:15.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •