Comparing EDB with Other Databases
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/28/2008
EDB provides enhanced functionality beyond CEDB. Furthermore, Microsoft SQL Server 2005 Compact Edition is available for developing more sophisticated database-enabled applications. This section discusses these three database engines, compares their features, and highlights the data compatibilities among the database engines.
For information about data type differences, see EDB Data Types and Size Limits.
When discussing database engines, it is important to understand differences in the terminology used for each engine. The following table compares common database engine terms:
| EDB and CEDB term | SQL Server Compact Edition term | Definition |
|---|---|---|
Sort order |
Index |
Key that provides an ordering for rows. |
Data type |
Data type |
Definition of the type of data stored in a property. |
Property |
Column |
One field of data. All data in a property is of the same data type. |
Record |
Row |
Set of information that contains data for each property. |
Database |
Table |
Collection of properties and rows of data. |
Volume |
Database |
Object store, created as a single file, that contains one or more databases in EDB/CEDB, or tables in SQL Server Compact Edition. |
Comparing EDB with CEDB
EDB and CEDB both create a volume at the top of a file. This volume contains one or more databases. Although EDB and CEDB share many features and use a similar API for accessing databases, EDB includes support for the following major features, unavailable in CEDB:
- Both explicit and implicit transactions
- Use of schemas to define the database structure
- Improved sort order support
- Support for stream data types
Conversely, the following CEDB features not supported by EDB:
- A shared system volume
- Tracking of the last modified time or the size of a database
- A default sort order
- Support for Microsoft eMBedded Visual Basic®. You must use Microsoft eMBedded Visual C++® when developing applications that use EDB.
CEDB Compatibility
EDB is designed as a complete replacement for CEDB. The differences in the functionality and features of EDB and those of CEDB are significant enough that a database created with CEDB is not accessible to EDB. An EDB database is likewise not accessible to CEDB.
To simplify application development, the EDB API is very similar to the CEDB API, with extended core functionality to include sessions, transactions, and stream data types. The EDB API is not fully compatible with the CEDB API, and applications written to use CEDB must be updated to use EDB.
For information about how a specific EDB function or structure differs from the CEDB equivalent, see the EDB Reference.
OID Compatibility in EDB
There are two main types of object identifiers (OIDs) in EDB: a database OID and a row OID. Each OID is guaranteed to be unique within a volume and does not change as long as the object exists. Once the object is deleted, however, the OID is released and can be reused by EDB when a new object, database or record, is created. Because OIDs are recycled, do not use them outside EDB to track EDB objects. Instead, use a CEVT_AUTO_I4, CEVT_AUTO_I8, or CEVT_RECID typed property to track records.
EDB uses its own OIDs to identify databases and records within a volume. While EDB support of OIDs is much like that of CEDB, EDB OIDs cannot be recognized or used by any of the object-store APIs. In EDB, an OID is the most efficient way to access a record because it gives the direct address to the record. Because OIDs are unique within a volume, you can use the volume GUID and the OID to uniquely identify an object.
Comparing EDB with SQL Server
EDB is based on the SQL Server 2005 Compact Edition engine, and so both share many core functions. However, SQL Server Compact Edition is designed as a complete database solution, providing not only the engine, but also a query processor, full data synchronization support, with merge replication and remote data access, with SQL Server, and row- and column-level tracking. SQL Server Compact Edition also supports much larger volume sizes. If your application uses very large volumes, SQL Server Compact Edition is a more appropriate database engine.
When developing applications that use EDB, develop your applications in Microsoft eMBedded Visual C++, and access features through the EDB APIs. When developing applications that use SQL Server Compact Edition, however, use the Microsoft .NET Compact Framework and the System.Data.SqlServerCe namespace.
Note
Databases created with EDB are not accessible through the SQL Server Compact Edition API, and SQL Server Compact Edition databases are not accessible through the EDB API.
See Also
Concepts
EDB Data Types and Size Limits
EDB Schema Support
Configurable EDB Volume Options
Multiuser Support in EDB
Using Notifications with EDB