Summary: This page contains the list of known issues encountered when porting an application to replace the use of CEDB with EDB.

The EDB API has been engineered to be call-level compatible with CEDB. This includes providing the same function names and parameter lists. Most code targeting CEDB will port to EDB with little or no changes. Compatibility with CEDB was an important goal for EDB but it was not the only goal. A great deal of effort has been put into making EDB more reliable, robust and secure then CEDB. As a result, some code may encounter compatibility issues and will need to be modified slightly. The following are the known compatibility issues.

*Performance Differences - In general, EDB provides substantially improved performance over CEDB. This is especially true when working with Persistant Storage (which is the case for all Windows Mobile 5.0 devices). One case where an application may experience reduced performance is when performing a large number of small writes. The reduced performance is actually a function of the underlying Persistant Storage behavior rather then EDB itself. As you would expect, the best way to overcome performance limitations caused by executing a large number of small writes is to rework the application to write data in larger blocks.

*Data Type Changes - Most data types behave the same in both CEDB and EDB. There are however some compatability issues caused by EDB's stricter handling of data types. The following are the data types known to have compatibility issues.
*CEVT_FILETIME - EDB requires that data of type CEVT_FILETIME be a valid date value when passed to CeWriteRecordProps . Previously, CEDB did not validate the value passed and would accept invalid values. This may be of concern if your application used an invalid date value such as 0 to identify special case dates, etc. At the time of this writing, this issue is not currently documented. (Thanks to MVP Riki June for reporting this one)