April 1, 2008 at 2:36 pm
hi everybody,
is it possible to hide my tables (i don't want customers to see my columns).
thanks.
April 1, 2008 at 2:46 pm
Create views that expose the data/columns that you want them to "see" and procedures to manipulate it. Then only give permissions to the "customers" on the views and procedures.
______________________________________________________________________
Personal Motto: Why push the envelope when you can just open it?
If you follow the direction given HERE[/url] you'll likely increase the number and quality of responses you get to your question.
Jason L. SelburgApril 1, 2008 at 4:00 pm
first of all thanks for your answer,
but i think it's my fault not to make my self clearer,
i mean that , i don't want my columns can be seen with sql server management studios , anybody can move my .mdf file to an sql server management studio and can see my tables names and my columns name can i prevent this to happen?
thanks again.
April 1, 2008 at 4:08 pm
There isn't a good way to do this. If people have Enterprise Manager and a login, they can look at the tables in the database.
Why can't they see the columns?
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
April 1, 2008 at 10:25 pm
oh, it's a sad thing for me to hear that there's no way :crying:,
i needed this because , i am an engineer and my tables structor(the columns in each tables,the relations between them) is a very hard solution of a difficult problem , it took a year of me to design all the structure and if i can't hide them any of my competitors can copy this solution easily and sell , may be i am bad but wanted to be the one (at least first year),
thanks again for your answers , thank you very much.
April 2, 2008 at 8:41 pm
delta dirac (4/1/2008)
oh, it's a sad thing for me to hear that there's no way :crying:,i needed this because , i am an engineer and my tables structor(the columns in each tables,the relations between them) is a very hard solution of a difficult problem , it took a year of me to design all the structure and if i can't hide them any of my competitors can copy this solution easily and sell , may be i am bad but wanted to be the one (at least first year),
thanks again for your answers , thank you very much.
That is why we have intellectual property protection laws.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
April 3, 2008 at 1:32 am
Obviously we do have intellectual property protection laws, however, enforcing these is a lot easier said than done.
April 3, 2008 at 1:50 am
many thanks for all the answerers ,
but ,,,, as an advanced database file (the sql i mean) was it too hard to protect it like a box or like a folder , 🙂 if i have the password i can open it and if not it's a closed box for me , i expected this from highly engineered sql database structure , and now i am really dissapointed 🙂
anyway thanks for all your nice interest and kindly answers.
April 3, 2008 at 9:17 am
delta dirac (4/3/2008)
many thanks for all the answerers ,but ,,,, as an advanced database file (the sql i mean) was it too hard to protect it like a box or like a folder , 🙂 if i have the password i can open it and if not it's a closed box for me , i expected this from highly engineered sql database structure , and now i am really dissapointed 🙂
anyway thanks for all your nice interest and kindly answers.
The issue is more that you can't prevent administrators/DBA's from seeing your stuff. Since they have access to the MDF file, they have the right to make themselves the owner, and - nothing denies the owner. Once you're the owner, well then - you can see pretty much anything else, can grant permissions to anyone else....
It's essentially the same problem as trying to deny security to the security administrator. Someone has to have access, and by then having access, you can't guarantee that others won't have access.
I mean - SOMETHING has to be able to read from your database file.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
April 3, 2008 at 10:11 am
Perhaps the best answer is obfuscation - change the names of all the tables and columns, so that even if they can see the structure, it's a lot more work to figure out what does what.
Pete
April 3, 2008 at 11:28 am
Ihave no experience using it, but wouldn't WITH ENCRYPTION be helpfull?
______________________________________________________________________
Personal Motto: Why push the envelope when you can just open it?
If you follow the direction given HERE[/url] you'll likely increase the number and quality of responses you get to your question.
Jason L. SelburgApril 3, 2008 at 11:34 am
The only real solution would be to offer your product only as a hosted solution where the users do not have direct access to the database.
If protection of your trade secrets is such a big concern, you seem to be addressing the problem rather late in the development cycle.
April 3, 2008 at 11:36 am
Jason Selburg (4/3/2008)
Ihave no experience using it, but wouldn't WITH ENCRYPTION be helpfull?
It doesn't protect DDL of physical objects. Meaning, as far as I've seen so far - it will encrypt what is IN the column, not the data structure itself.
Even then - unless you go to some rather extreme lengths - running profiler will "reveal" the unencrypted version of pretty much any encrypted stored procedure, etc... The compiler has to have it unencrypted, so the WITH ENCRYPTION is more obfuscation than actual encryption.
Besides - once you've encrypted everything, your system will spend so much time encrypting/decrypting everything, you might as well go back to using MS Access.... Especially when you consider that it will destroy any indexing you have (the indexing will happen on the ENCRYPTED version of the column, so your sorting gets shot to hell).
Fun stuff.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
April 3, 2008 at 12:40 pm
yucky
______________________________________________________________________
Personal Motto: Why push the envelope when you can just open it?
If you follow the direction given HERE[/url] you'll likely increase the number and quality of responses you get to your question.
Jason L. SelburgApril 6, 2008 at 12:24 am
*sigh*
Folks, the solution to this problem is the same as what Microsoft uses for its own database-oriented products like Sharepoint:
1) Split the implementation between Client software & DB structures.
2) Name the DB tables and columns confusingly: use the same names for completely different things.
3) Don't document anything.
4) Void the warranty if anyone tries to change anything by bypassing the front-end.
5) Employ lawyers and use them.
There's just no point to trying to design a technological solution to what is inherently a human and legal problem. I assure that not even encryption, hosting, heck, encryption WITH hosting, nor any other technological solution addresses the full protection that dirac actually needs.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply