** More mind shift info **

Published 30 June 04 10:42 AM

I should also point out that in VS Beta 1/SQL Beta 2, this Xcopy functionality is limited to those with admin rights.  In the next beta, non-admins will have Xcopy capabilities as well.   So, joe user that gets my app and database, that is a normal (read: non-admin) on his machine, will be able to run his app directly as well. 

Some have asked questions about security threats, etc.  By default, SSE has networking turned off.  The default authentication mode is NT Auth. 

Think of SSE as your starting point for database application development.  It's very easy to use and, it *is* SQL Server.  When your app grows up beyond single machine needs, and you want to turn networking on, or move it to a full fledged SQL Server installation -- it's a simple painless conversion.  Depending on what you want to do you either just turn networking on for SSE or you move your MDF to a server and attach it (and change the connection string in your app's config file.)

by vsdata
Filed under: , ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Ronny Ong said on June 30, 2004 9:51 PM:
I left my comments on the previous post before I saw this, but I remain unconvinced that this is a good idea. I'd like to know more specifically how the next beta would deal with the default NTFS permissions of the Program Files tree if Joe User logically tries to XCopy the app under there, or will XCopy deployment require using a path outside Program Files?

And what if Joe User chooses a path in "My Documents" except that he doesn't realizes that his "My Documents" is part of a roaming profile, or is configured via group policy for Folder Redirection? Even if the mdf and ldf aren't big, the exe might be, and it would definitely be a waste to send a static exe across a 56Kbps leased-line (yes, slow WANs still exist, even near major metropolitan areas) or wireless connection, or to back it up constantly.

These are solvable issues, in the same way that roaming profiles gained special understanding of the "Temporary Internet Files" directory tree in the late 90's after IE had become popular and burned a lot of networks, that the Offline Files feature in Windows has special recognition of Access/Jet MDB files, that SQL Server SP3 and Windows Server 2003 Volume Shadow Copy are specifically aware of each other, that Explorer displays a special warning when you (presumably mistakenly) try to open dozens of documents at the same time, etc. I just hope adequate thought has been given to all possible special scenarios.
# Ming Chen said on July 1, 2004 12:25 AM:
Ronny, I had follow up your post on the previous post (see the link)

http://blogs.msdn.com/vsdata/archive/2004/06/29/169288.aspx#170602


Thanks,

-Ming
# Lance Delano said on July 1, 2004 9:11 AM:
*Generally*, it will be such that if the user has write access to a physical location, the user will have the ability to access to the MDF. The thing to keep in mind here is that all of the corner scenarios can be handled with existing functionality. Xcopy capabilities do not replace existing functionality, they agument it. The scenario that is more fully enabled with Xcopy is the quick start scenario and the specific knowledge necessary to make it work. It's a removal of a barrier to entry and start.

Leave a Comment

(required) 
(optional)
(required) 

  
Enter Code Here: Required

This Blog

Syndication

Bookmark and Share

Add to Technorati Favorites

Bookmark on MSDN

NOTE: These postings are provided "AS IS" with no warranties, and confer no rights. Use of included code samples are subject to the terms specified at Microsoft - Information on Terms of Use
Page view tracker