Design strategy

  • I recently built a new database which will be used by sales agents to track and log their transactions. This was orginally built as a stand alone database for a single agent, but demand and interest has hightend and I need to open this up to many agents needing a solution such as this. One of the issues I'm having is how I should impliment the security within the database so that agent1 cannot look at agent2's information. Or should I build a separate database for each agent and host it on one instance of SQL Server? Any help on this would be greatly appreciated.

    demicoq

  • This was removed by the editor as SPAM

  • It seems you are troubled by your own success.

    If you want an easy solution, make multiple databases.  This is however Kludge in that you are not able to share any of the resources.

    To do it "right" may be a major undertaking.  here are a few things to consider:

    1.  All of the tables that hold user data will need an aditional column added to them for a USERID. 

    2.  You will then need to have a table for User information including a password.

    3.  You will have to make a User logon screen that  Checks against the username and password before allowing the restr of the app to run.

    4.  You will have to change all of your calls to the data to include the USERID and then filter all of the results by that USERID.

    5.  You will probobly need to make some sort of an administration application so that you do not have to be responsible for adding users and passwords by hand directly into the tables.

    This is just a short list that I could think of in a few minutes.  I hope it helps.

    Tal McMahon

     


    Kindest Regards,

    Tal Mcmahon

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply