This document examines both SQL options in the Symbian OS: Symbian SQL and SQLite.
If you are creating or porting an SQL capable application to Symbian OS you should read this document to get a better understanding of the issues and options.
Intended audience:
This document is intended to be used by Symbian OS licensees and third party application developers.
Symbian OS exposes two interfaces to SQL:
the Symbian SQL component of Symbian OS
the open source SQLite 3 API.
If you are developing an application for Symbian OS which involves accessing a database with SQL you must decide which of these interfaces to use before you begin. This is for two reasons.
It is not possible to access the same database with both interfaces, whether concurrently or not.
The two interfaces are different and do not have identical functionality.
Choose an SQL interface
Here is a simple set of rules to help you select the interface most appropriate to your development needs.
The advantages of using Symbian SQL to develop a Symbian OS database application are its close integration into the Symbian OS platform as a whole and the consequent robustness, efficiency and security that this provides.
Symbian SQL is robust because applications are isolated from the server. Errors in the application do not affect the server and vice versa.
Symbian SQL is robust because an application can be configured to be included in database backup and restore.
Symbian SQL is efficient because multiple applications share one instance of a database cache. The server has a single connection to the file system and there is no need of multiple caches that duplicate the use of memory.
Symbian SQL is efficient because the single connection from the server to the file system eliminates the need for mutexes. This makes efficient use of kernel resources.
Symbian SQL is efficient because it sets up a soft heap limit. This means that the server reuses free memory before it attempts to allocate more. The limit may still be overridden, for example when a blob or a large text column is accessed. This limits RAM usage.
Symbian SQL is efficient because it provides asynchronous APIs. This allows the application to make a database call and perform other work while it waits for the call to return.
Symbian SQL is efficient because the server is single threaded and no file locking mechanism is required.
The advantages of the SQLite 3 API are its open source status, excellent documentation, widespread use and large developer community. For a single cross platform application written by a team of developers it may not be worthwhile mastering the C++ interface and to use the SQLite 3 API instead.
The SQLite 3 API exposes many functions not available in Symbian SQL, particularly the SQLite C extension API. However, it should be noted that Symbian SQL provides several built-in collation functions and a built-in implementation of the LIKE operator.
SQLite 3 API supports multi-threaded applications and provides concurrent database access.
If you are creating or porting an SQL capable +application to Symbian platform you should read this document to get a better +understanding of the issues and options.
Intended +audience:
This document is intended to be used by Symbian platform +licensees and third party application developers.
Symbian platform exposes two interfaces +to SQL:
the Symbian SQL component +of Symbian platform
the open source SQLite +3 API.
If you are developing an application for Symbian platform which involves +accessing a database with SQL you must decide which of these interfaces to +use before you begin. This is for two reasons.
It is not possible to +access the same database with both interfaces, whether concurrently or not.
The two interfaces are +different and do not have identical functionality.
Choose +an SQL interface
Here is a simple set of rules to help you select +the interface most appropriate to your development needs.
The advantages of using +Symbian SQL to develop a Symbian platform database application are its close +integration into the Symbian platform as a whole and the consequent robustness, +efficiency and security that this provides.
Symbian SQL is robust +because applications are isolated from the server. Errors in the application +do not affect the server and vice versa.
Symbian SQL is robust +because an application can be configured to be included in database backup +and restore.
Symbian SQL is efficient +because multiple applications share one instance of a database cache. The +server has a single connection to the file system and there is no need of +multiple caches that duplicate the use of memory.
Symbian SQL is efficient +because the single connection from the server to the file system eliminates +the need for mutexes. This makes efficient use of kernel resources.
Symbian SQL is efficient +because it sets up a soft heap limit. This means that the server reuses free +memory before it attempts to allocate more. The limit may still be overridden, +for example when a blob or a large text column is accessed. This limits RAM +usage.
Symbian SQL is efficient +because it provides asynchronous APIs. This allows the application to make +a database call and perform other work while it waits for the call to return.
Symbian SQL is efficient +because the server is single threaded and no file locking mechanism is required.
The advantages of the +SQLite 3 API are its open source status, excellent documentation, widespread +use and large developer community. For a single cross platform application +written by a team of developers it may not be worthwhile mastering the C++ +interface and to use the SQLite 3 API instead.
The SQLite 3 API exposes +many functions not available in Symbian SQL, particularly the SQLite C extension +API. However, it should be noted that Symbian SQL provides several built-in +collation functions and a built-in implementation of the LIKE operator.
SQLite +3 API supports multi-threaded applications and provides concurrent database +access.