Following is a list of additions to UltraLite introduced in version 10.0.1.
New platforms and devices Windows Vista is now supported in this release.
Improved SQL performance Historically, UltraLite would default to using the primary key index if, the UltraLite query optimizer determined that there was not any benefit to using an existing index for the query.
With this version, instead of using the primary key, UltraLite will now access rows directly from the database pages. When this happens, you can expect to see query results returned in a different order from previous releases, because rows are no longer ordered by the primary key index. If the ordering of data is a concern, use an ORDER BY clause in your query. See Using direct page scans and Using index scans.
Database property and option accessibility via SQL Previous versions only allowed you to access database properties and options with methods from each UltraLite API. Now, UltraLite SQL introduces the following statement and function, so that you can set and retrieve properties and options via SQL (including Interactive SQL):
the SET OPTION statement. See SET OPTION statement [UltraLite] [UltraLiteJ].
the DB_PROPERTY function. See DB_PROPERTY function [System].
Increased number of concurrent connections UltraLite now supports more concurrent connections. A single database still supports 14 connections. However, the number of overall concurrent database connections have increased:
8 databases and 16 concurrent connections for Palm OS and Symbian OS.
32 databases and 64 concurrent connections for all remaining platforms.
The total number of SQLCAs you can use to connect to the engine is 31. Keep this number in mind knowing that some components use one SQLCA per database manager and one SQLCA per connection. That means, for example, if your application is using the UltraLite.NET API, your real connection limit is reduced to a total of 30 connections only.
Commit flush operations Historically, any commit operation performed with either the COMMIT statement or API call would only complete after UltraLite flushed a transaction safely to storage. With this release, you can now configure these behaviors and logically separate them as distinct operations:
A logical commit now gives you the ability to roll transactions back in an application.
A checkpoint now gives you a recovery point after a failure. This allows you to recover to the last committed transaction that has been flushed to memory.
However, you can also enhance the performance of UltraLite applications that use the autocommit feature—particularly if you use group commit flushes. See Backing up and recovering data in UltraLite and Flushing single or grouped transactions.
This new behavior is supported with the following features:
The CHECKPOINT statement. See CHECKPOINT statement [UltraLite].
The Checkpoint methods for the UltraLite embedded SQL API and C++ API components. Other languages must use the CHECKPOINT statement instead. See:
The COMMIT_FLUSH connection parameter. See UltraLite COMMIT_FLUSH connection parameter.
The commit_flush_timeout and commit_flush_count database options. See UltraLite commit_flush_timeout option [temporary] and UltraLite commit_flush_count option [temporary].
 |
Discuss this page in DocCommentXchange.
|
Copyright © 2010, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.0 |