From Clarion NG
Hi Charles,

So, basically my SQL research from long ago may actually be correct, or I am
now very confused with regards to what Bernard said.<g>

If you are correct, then basically there is no real database protection when
one chooses to use an SQL backend for a commercially sold product. Any dba
or consultant could easily accomplish the goal of gaining access to any SQL
db without the need for permission from the original dev. Your comment#2
suggests that this is really a trivial thing to accomplish.

I certainly agree with your comment#3... I'm not looking to lock a user out
of their own SQL Server totally (just when it comes to my apps).
I simply wanted to know if SQL backends provided a secure means of blocking
all users (dba's, consultants, end-users, etc.) from conjuring up a way to
gain access to the database (assuming the user had full access to the server
which held the database).
IMO, this is what a TPS file brings to the table. Nobody can read a single
file without contacting me, the developer. I remember a few years ago, I
had a smart cookie try to gain access by purchasing the ODBC from TS. They
found out later that they still needed the password.<seg>


Can someone confirm that Charles statement is in fact true?
It certainly corroborates my initial findings some years back.

I am simply trying to confirm whether or not a secondary password or method
now exists that truly locks all dba's and wannabe consultants from TOTALLY
prying into an SQL database without the use of my application?


I seem to have conflicting information on this matter.
Either way I'm going to go SQL in my future projects, but I want to know
what I'm up against.<g>

Later,
Doug



"Charles Maples" <CharlesM@...> wrote in message
news:A921.1081214137.17079@......

> Hi Doug
>
> few things you need to remember
> 1) in most cases a user will only be running a single instance of a SQL db
> on the server machine so they will need to have the sa password to

maintain

> their other databases
> 2)if you lock them out of one instance of the server all they have to do

in

> MSSql is to copy the db files to another SQL server they have sa access to
> and then attach the db then they will have full access
> 3) in many cases the customer will already be running a full sized sql
> server and they would be very unhappy if you locked them out of it
>
> Charles
>
> "Doug" <S-P-A-M-A-W-A-Y-dougi@...> wrote in message
> news:A921.1081182160.16853@......
> > Steffan,
> >
> > > Beside this, remember, that the information in the clients database
> > > WAS
> > > BOUGHT by you client and you have no right to disallow him to access
> > > it in
> > > any way he wants to. You might be allowed to make it a little harder.
> > Not true (at least in the U.S.). The customer's right to the software

and

> > database are defined by the developer, not the customer. Your license
> > agreement clearly dictates what the user has rights to do or not do with
> the
> > application. The database is still theirs... but that doesn't extend
> their
> > rights on how they gain access to it.
> > I had an issue some years ago where I wanted to convert a client over to
> our
> > software. I needed access to a competitor database and wanted to see if

I

> > could get the passwords to gain access to a db. My attornies told me

that

> > there was little that could be done. A password on a db is considered a
> > trade secret. The other developer had done nothing illegal by placing a
> > password on the db to protect his database design.
> > Unless the license agreement clearly states that you must provide the
> > end-user the ability to gain access to a db from external tools or

provide

> > the password, you don't have to conform.
> > My attorney basically told me that if the user could print the database

on

> a
> > report, or visually pull up each record on screen, then your program has
> in
> > fact provided a means for access to the database which is owned by the
> > customer. No U.S. law exists (and I doubt too many other countries)

that

> > says that a large database requires the developer to provide an easier

way

> > of electronically gaining access to a db.
> >
> > I know of many commercially available applications that give me no

rights

> to
> > the database via special db tools. In fact, the very popular Quickbooks
> is
> > one of them.
> >
> > >
> > > So simply don't try it. Offer such a good service, that he will
> > > prolong this
> > > support agreement. Then don't bother.
> >
> > It's not about giving good service or not. It's about ensuring that you
> > don't spend countless hours trying to solve a database corruption issue
> that
> > was not caused by you. Developer time is valuable, and a customer who
> hires
> > a dba to mess with the database without understanding the underlying

code,

> > should be held accountable for their actions. Customers will rarely

admit

> > to this knowing that a developer will bill them for every hour he/she
> spends
> > fixing up the screw-up.
> > The other main reason for doing this is to protect your investments.
> Access
> > to a database design, is pretty much access to the crown jewels of an
> > application. An application with many triggers and sp, even more so.
> >
> > Later,
> > Doug
> >
> >
> > >
> > > Regards,
> > > Steffen
> > >
> > >
> > >
> >
>
> --------------------------------------------------------------------------
> > ------
> > > Yahoo! Groups Links
> > >
> > > To visit your group on the web, go to:
> > > http://groups.yahoo.com/group/firebird-support/
> > >
> > > To unsubscribe from this group, send an email to:
> > > firebird-support-unsubscribe@yahoogroups.com
> > >
> > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
> > >
> > >
> > >
> >
> >
> >
>
>
>

JVZ Systems CC Customised Software - When it needs
to fit like a glove

Johan van Zyl
Owner JVZ Systems CC
PO Box 3469
Somerset West
7129
johan@... http://www.jvz.co.za tel:
fax:
mobile: +27 21 851 7205
+27 21 852 2387
082 875 4238




Signature powered by Plaxo Want a signature like this?

Add me to your address book...


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 2004-03-31


[Non-text portions of this message have been removed]