Subject Re: [firebird-support] Re: RE: How would Firebird prevent users thrasing database
Author Rafael Szuminski
> Not only that (which I agree with), but I'll tell you how it works
> in real life. In real life, your single biggest client comes to you and
> says "we want to be able to access your files in order to do x, y or z".
> (In our case "because our chartered accountants have written a web based
> MIS system that will draw data from your files".) So now you have a choice.
> Either you tell your biggest client to go to hell (and make sure that it's
> a multi - billion $ international corporate while you're doing it, like
> ours is), or you have to write a whole bunch of work arounds and extra code
> to allow them to do that.
>
> Or else you get a huge "opportunity" - a possible sale - which falls
> through because their IT guys are as sharp as you are, and think that this
> idea of you holding them to ransom isn't actually a very good idea.
>
> Or else the engineering manager and the support manager tell the board that
> it is extremely difficult for any of the 50 or so field engineers to
> support the program in the field, because of all the extra security you
> have put in place to make sure that no - one except you understands what
> you've done.
>
> Or else your product target market becomes more and more limited because
> your application can't speak the standard Structured Query Language, and
> nobody exept you can fix it when it's broken.
>
> Where did you learn your programming style? Microsoft? :-)
>
> In my experience, the kind of security spoken about is far more trouble
> than it is worth, and limits your options severely. Hell, IMHO, even
> password / user level security is only worth all the effort in very
> specific cases - and then NEVER to "protect" my own code - like in
> Financial or Asset management systems, where you want to see who has done what.
>
> Regards
>
> Tim

Amen to that. In the past two years we have signed up multiple new clients just
because unlike our competition we give them full access to the db (including
support and training). Of course we have them sign a paper that we are not
responsible for data damadges... :-)