I think we're going to have to just disagree here.

There are numerous ways that someone could get the data: detach the database, do a backup, or bulkcopy the data out. There's probably more.

Detaching the database requires the "bad guy" to access SQL Server as a member of the sysadmins server role. Backup is a little more flexible but the backup has to be written somewhere where SQL Server has permission and not the logged in user.

While someone could stop SQL Server and copy the files, IIRC, only members of the local admins group can start and stop SQL Server. Also, unless you detach the files, you can't just reattach them using sp_attach_* (but it is possible)

I believe that the detach/reattach logs an entry to the error log. I know that the backup does.

And let's not forget about the possible amounts of data that we're dealing with. It's unlikely that it'll fit on a floppy. If the files are under 640MB, you could burn them to a CD. I suppose you could FTP the files somewhere.

>A Excel/Access file have a open password.

Excel and Access probably have passwords because of their convenience. You typically don't have a mass of SQL Server database lying in a folder on a server.

>I think you are joking.

Nope. The client that I had mentioned developed secuity software for large transportation facilities (the specifics are not important). The standard install was to put the servers in a vault so that no one ran off with the harddrives.

BTW, if you're worried about the local admins logging into your SQL Server, you can remove the local admins group from the sysadmins server role.

Also, if you're trying to prevent your customers from access the data outside of your application, there is merit to that. I've had many occurances where customers have used Access to manually manipulate the data and cause havoc. OTOH, the data usually belongs to the customer and they might want access to it in order to do things that your app may not provide out of the box. One of the benefits of SQL Server, IMO, is that I can give my customer read-only or limited-write access to their data and enforce it via the database engine instead of my application.

BTW, MS hasn't shipped SQL Server 2005 yet. You could always send this as a enhancement request: sqlwish@microsoft.com is the email address I believe.

-Mike

>
>huh?
>
>It's hard to protect your data (regardless of the source, product, or vendor) when the "bad guy" has physical access to the machine - especially with, or close to, admin permissions.
>
>
>Sorry Michael, my i'm not agree with you.
>
>A absolute protection is hard to implement, but a minimal protect level is simple.
>
>A SQL BACKUP have a password.
>
>A Excel/Access file have a open password.
>
>Add a password to the SQL database files is not a hard task.
>

>CREATE DATABASE ... PASSWORD 'BLABLA'
>

>
>If this is done well, with a long password i can protect the database structures without reasonable problems.
>
>
>If you're so worried about this, physically secure the server. I once dealt with a client that housed the server in a vault
>
>
>I think you are joking.
>I write applications for thirds party, and therefore as I can prevent the physical access to the hard disk of the server?
>I must sell one together room armored to the application?
>
>Fabio