Collection Contents Previous Next PDF

UltraLite Database User's Guide

Welcome to UltraLite

Choosing an UltraLite programming interface

Choosing between components and static interfaces


UltraLite applications are built using either an UltraLite component or a static interface.

The choice of which to use depends partly on the language you wish to use. If you are a C#, Visual Basic, or JavaScript programmer, you should choose an UltraLite component. If you are a C/C++ or Java programmer, you have a choice between using a component or a static interface. This section compares components and static interfaces.

Data access features 

UltraLite components can use either dynamic SQL or a table-based API to access data.

You can combine dynamic SQL and the table-based API in a single application.

Static interfaces (embedded SQL, the Static C++ API, and the static Java API) use SQL to access data. A wider range of SQL is supported in the static interfaces than in dynamic SQL, but all queries must be specified at compile time. For example, UNION and FULL OUTER JOIN queries are currently supported only from the static interfaces. In both static and dynamic SQL, queries can contain parameters, for which you can supply values at runtime.

The Static C++ API also provides a table-based API, which has some of the benefits and limitations of the component table-based API. For a description, see Developing Applications Using the Static C++ API.

Application size 

The UltraLite components include code to parse, optimize, and execute arbitrary queries. In contrast, the static interfaces generate code that executes specified queries, but do not need to generate code to parse or optimize queries. For this reason, applications built using the static interfaces are typically much smaller than those built with UltraLite components.

As the number of queries and tables in the database increases, the size advantage of the static interfaces is lost. For complex applications using many queries and addressing databases that contain many tables, the components can be smaller as they do not need to contain code for each separate query.

Development model 

Each UltraLite component exposes an object-oriented API designed to be familiar to users of the language supported by that component. The development model is similar to that for many other kinds of applications.

The UltraLite static interfaces require a more complicated development model, in which a preprocessing step generates application code from a reference database.

For many users, the UltraLite components are easier to learn than the static interfaces.

For more information, see the following sections:

Performance 

Queries included as part of an application that uses a static interface are already parsed and optimized. Therefore, they may perform better than queries in UltraLite components. The optimization of queries in the static interface depends on the distribution of data in the reference database. The closer the data in the reference database is to that in the UltraLite database, the better the performance will be.

For more information about Adaptive Server Anywhere SQL support, see SQL Statements.

Compatibility with Adaptive Server Anywhere 

Embedded SQL provides a common static programming interface for UltraLite and Adaptive Server Anywhere databases. ADO.NET and ODBC provide programming models that are shared between UltraLite components and Adaptive Server Anywhere.

Maintaining a common interface may be particularly useful on platforms such as Windows CE, where both databases are available. If you need to move from UltraLite to the more powerful and full-featured Adaptive Server Anywhere database, using embedded SQL, ODBC, or ADO.NET makes migrating your application easier.


Collection Contents Previous Next PDF