Results 1 to 11 of 11
  1. #1
    Join Date
    Jul 2003
    Location
    Penang, Malaysia
    Posts
    212

    Unanswered: How to prevent *.mdf file copied to another database?

    How do I prevent my staff from copying *.mdf files out from the company?

    Normal staff will not have password access to the database. But then, they can always shutdown the SQL Server Services Agent. And manually copy the file from the appropriate folder.

    Paste it in their own machine, attach it back and it can be seen.

    Is there any setting somewhere I'm missing? Please advice.
    Sorry if this is a repeated question.
    Patrick Chua
    LBMS ( Learn By My Self) NPQ ( No paper Qualification )

  2. #2
    Join Date
    Nov 2003
    Location
    Christchurch, New Zealand
    Posts
    1,618
    So they don't have access to the db but they do have access to the file system on the server hosting the db??

    What?!?

    Your database can only be as secure as the file system that it resides on which is only as secure as the operating system the the file system runs under....

    Secure the file system and you won't have a problem.

  3. #3
    Join Date
    Feb 2002
    Posts
    2,232
    Why do they access to the services on the sql server box ?

  4. #4
    Join Date
    Jul 2003
    Location
    Penang, Malaysia
    Posts
    212
    If the SQL Server is stored at Server and staff accessing it from Client Base PC then it is not a problem

    This problem arises when it is a Personal Edition SQL Server where database and application runs on the same PC. Usually because of budget constraints.So they don't have SQL Server authentication to the DB but they can acess the file system.

    Securing the file system is what I thought so too. I tried testing registering the SQL Server Agent service under an administrative account and the staff log-in as a normal user.

    So far, this has prevented the normal user from even accessing the MSSQL file system.

    Is this the best way to solving this problem?
    Or is there any other way?
    Patrick Chua
    LBMS ( Learn By My Self) NPQ ( No paper Qualification )

  5. #5
    Join Date
    Nov 2003
    Location
    Christchurch, New Zealand
    Posts
    1,618
    Hmmmm,...not sure if it is the "best" way,... but it's what I would do...

  6. #6
    Join Date
    Feb 2002
    Posts
    2,232
    It sounds like in your situation you chose the best solution - giving the users limited access. I still question why you have to use personal edition - but that is your decision.

  7. #7
    Join Date
    Nov 2003
    Location
    Christchurch, New Zealand
    Posts
    1,618
    I assume he has the situation that a lot of us have and that is that X, Y and Z are what he has to work with....

    You can't convince all your customers that spending a bit more money in the sort term would be in their interests in the long term.

  8. #8
    Join Date
    Feb 2002
    Posts
    2,232
    That is why access and msde exist.

  9. #9
    Join Date
    Nov 2003
    Location
    Christchurch, New Zealand
    Posts
    1,618
    Access is hardly as functional MS SQL. This might should stupid, but what is MSDE?

  10. #10
    Join Date
    Jul 2003
    Location
    Penang, Malaysia
    Posts
    212
    If I'm not mistaken,MSDE is SQL Server Desktop Engine...right??
    It is a data engine build on SQL Server tech.

    I myself haven't gone into this in detail yet. This might just be what's needed for my future applications.

    Thanks for informing me this .
    Patrick Chua
    LBMS ( Learn By My Self) NPQ ( No paper Qualification )

  11. #11
    Join Date
    Feb 2002
    Posts
    2,232
    Patrick - You are correct.

    rokslide - If you are using the Personal Edition of Sql Server then robust functionality is not at the height of your concerns. Access is perfectly functional for stand alone use for most scenarios otherwise use msde.

Posting Permissions

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