What Are the Issues?
I've been extolling the virtues of the MSDE edition of SQL Server for quite some time. That's because I'm convinced that MSDE is a far better solution for applications that need a "few-user" data store, or where an application does not have access to a remote DBMS engine. While MSDE has been widely adopted by a large number of serious businesses, they often have to deal with a number of issues on their own—implementing non-standard solutions that sometimes conflict with other companies' attempts to solve the same or other issues. These include:

Deployment: How is SQL Server installed along with an application? There is a litany of related issues here. For example, what if SQL Server is already installed? What if the instance name collides with other existing instances? Should the application share an existing SQL Server instance or create a unique instance? What happens when the application that installed the shared SQL Server instance is uninstalled—should it also uninstall the SQL Server instance? If so, what happens to the other databases that instance is hosting?

Security: If you choose to share an instance of SQL Server, what password should be used for the SA? How can user accounts be setup? Should the application simply use integrated security managed by the domain controller? What if there is no Active Directory? How are databases installed on the target MSDE server? After installation, is the database visible to other applications on the server? How can applications hide proprietary data?

Performance: MSDE uses a governor that limits the number of simultaneous operations on the server. What if your single-user application needs to perform several operations at once but the governor kicks in and slows it down? Frankly, I'm not sure this issue is that widespread. I've heard very few people complain that the governor kicked in and made their application run too slowly. Sure, I've heard of applications not running particularly fast, but these were (generally) caused by brute-force queries or "challenged" database implementations.

Scalability: MSDE databases are limited to 2GB. What if you need to store more data than that? Does it mean you must upgrade your target systems to use a SQL Server Standard Edition that might cost more than the systems that expect to use it? Again, most of the complaints I've heard about involve when people stored binary large objects (BLOBs) like documents or pictures in the database. Once they replaced the BLOBs with a path to the BLOB file, their databases shrunk down to a reasonable size.

Tools: The MSDE version of SQL Server is the "deployment" configuration. As such, it does not include any tools needed to administer the server or the databases it manages. I usually recommend that developers buy the $49 (SRP) Developer Edition that includes the full suite of tools to manage their MSDE databases. However, due to licensing restrictions, these tools cannot be deployed with an application. This means developers have to build their own client-side tools or simply build needed functionality into their deployed applications.

Administration: Regardless of how it's done, applications must take on quite a few administrative responsibilities. This is especially true for SQL Server Express systems where there is no "SA" (system administrator) at the keyboard. These admin responsibilities include managing the Login Account(s), permissions, backup, restore, and log maintenance. Your end user is not usually capable of, and should not be trusted to perform, these operations—it's up to your application to do so. While JET databases needed periodic compression or repair, MSDE (and any SQL Server database) needs to periodically back up (and dump) the logs and database. This issue becomes fairly significant when the database is not managed centrally, where administrative and maintenance tasks can be more easily managed. Again, this is up to your application to do.

Service Packs: Since MSDE is often embedded in applications, users might not know that they have an instance of SQL Server installed. As such, they aren't aware that they might need to post a SQL Server service pack to protect their data and systems from attack even if they see it on the 5 o'clock news. To help prevent some of the problems caused by worms and other attacking viruses, MSDE SP3(a) disabled network connectivity so applications are unable to connect to the server over the intranet (or Internet). The problem is that the service pack was not applied to many systems because users did not know it was necessary, nor did they know how to apply the patch. This issue notwithstanding, posting SQL Server updates to MSDE installations is problematic, as the Microsoft upgrades don't always work with custom setup scripts used to deploy MSDE applications and databases.


source : http://msdn2.microsoft.com/en-us/sqlserver/aa336270.aspx



---------------------------------


Related :

UsingCrystalReports6
VerifyUserEmailAddressPHP-1
VerifyUserEmailAddressPHP-2
viewinformationvb2005
WatermarkImagesFlyPHP-1
WatermarkImagesFlyPHP-2
WhatAretheIssues
What-isMySQL
WhatSQLServerExpress
writefileinvb2005
WritingFileDialogBox
SimpleDatabasevb6
SQLServer2005fromVisualBasic6
SQLServer2005withPHP
SQLServerSecurityGuidelines
TransferringFiles
UsingCrystalReports6