Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
denis_the_thief
Aged Yak Warrior
596 Posts |
 Posted - 2013-05-30 : 17:25:18
|
| Our Customer has begun added things to the Database we provide for our application. They are adding their own tables in the Database, Triggers, Stored Procedures and Functions. They are even using our own naming scheme for some Stored Procedures. About the only thing they are not doing is adding columns do our tables.No one can tell by looking at something wether it is "ours" or "theirs". Ideally I think they should be adding this in a different Database or a separated Schema. Or at the least, they should have their own naming prefix. I am worried we get into a situation where we need to investigate something and we can't tell who the Stored Procedure belongs to.Has any one been in this situation? What do your customer do in these cases? What reasons can I give the customer to adopt some sort of naming prefix of their own rather than using ours?Or am I making something out of nothing? |
|
|
James K
Master Smack Fu Yak Hacker
3873 Posts |
Posted - 2013-05-30 : 17:41:13
|
| If at all possible, I would avoid giving that level of access on my database to end users. You could create another database on the server and have them do their thing in that database. If they need to access some of your data or procedures, you can grant them access on an as needed basis. You can do cross-database querying using 3-part naming convention.If you do give access to your database, then I don't see a reasonable way in which you can support the database. It's possible, but very painful and painstaking. |
 |
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2013-05-31 : 00:37:00
|
| While I agree with much of what James said...from what I know of your business from other threads, there isn't much you can do to control this.I would suggest going forward using a schema that is not dbo, making it unlikely they will choose to use your schema.More importantly, everything you provide, should be documented on your end so there is NO AMBIGUITY as to whether it is yours or theirs. Any doubt in this matter is 100% unacceptable. And as the vendor, you should not be supporting any database that the end user modifies. Document what you support and make it part of the agreement between vendor and client. |
|
|
|
Lamprey
Master Smack Fu Yak Hacker
4614 Posts |
Posted - 2013-05-31 : 13:09:34
|
| I assume you have verbiage in your sales/support agreement about this? If not, then you are out of luck. If so, then you have a nice agreement that you can point to when there are issues and they probably won't have much ground to stand on. |
|
|
|
MIK_2008
Master Smack Fu Yak Hacker
1054 Posts |
Posted - 2013-05-31 : 15:00:21
|
| I agree with James, Russel and Lamprey, but I don't see a narrative for why yours company has allowed that much of access to the clients to make structural changes in yours database(s)? The only reason I can think of is that its should be done only if they are part of your company/organization (but then they won't be "client"). But you mentioned that they are client, and from client perspective, its only "the data" which they might require from yours side. With that, I would suggest same as mentioned by James to seperate your structures/database(s) from their(s). Create a different database for them. If they require any data from your database simply either grant permissions to the procedures through which they can access your data or create new ones for them.CheersMIK |
|
|
|
denis_the_thief
Aged Yak Warrior
596 Posts |
Posted - 2013-05-31 : 15:04:06
|
Thankyou for your responses. Good to know you agree with me.quote:
Originally posted by russell
While I agree with much of what James said...from what I know of your business from other threads, there isn't much you can do to control this.
Good point. We only have read-access to the Database. We develop and then provide the updates (i.e. Database scripts). At least they don't modify our Stored Procedures. |
|
|
|
denis_the_thief
Aged Yak Warrior
596 Posts |
Posted - 2013-05-31 : 15:32:26
|
quote:
Originally posted by MIK_2008
I agree with James, Russel and Lamprey, but I don't see a narrative for why yours company has allowed that much of access to the clients to make structural changes in yours database(s)? The only reason I can think of is that its should be done only if they are part of your company/organization (but then they won't be "client"). But you mentioned that they are client, and from client perspective, its only "the data" which they might require from yours side.
It is their Database so from a security point of view and from an Audit Compliance point of view, we can not modifiy anything on 'their' system. Even the upgrades/modifications are performed by them, we only provide. They do respect us in terms that they do not modifiy any of our code. But they problem is that they are adding so many things and not using a naming scheme or as you say, should be adding things in another schema/database.But actually, yes we are the same company but different country in many cases. |
|
|
|
|
|
|
|
|
Protect Naming scheme from Customer