ACTIONSCRIPT 3 Developer’s Guide en

ACTIONSCRIPT 3.0 DEVELOPER’S GUIDE
Working with local SQL databases in AIR
Best practices for working with local SQL databases
Adobe AIR 1.0 and later
The following list is a set of suggested techniques you can use to improve the performance, security, and ease of
maintenance of your applications when working with local SQL databases.
Pre-create database connections
Adobe AIR 1.0 and later
Even if your application doesn’t execute any statements when it first loads, instantiate a SQLConnection object and
call its open() or openAsync() method ahead of time (such as after the initial application startup) to avoid delays
when running statements. See “Connecting to a database” on page 725.
Reuse database connections
Adobe AIR 1.0 and later
If you access a certain database throughout the execution time of your application, keep a reference to the
SQLConnection instance, and reuse it throughout the application, rather than closing and reopening the connection.
See “Connecting to a database” on page 725.
Favor asynchronous execution mode
Adobe AIR 1.0 and later
When writing data-access code, it can be tempting to execute operations synchronously rather than asynchronously,
because using synchronous operations frequently requires shorter and less complex code. However, as described in
“Using synchronous and asynchronous database operations” on page 752, synchronous operations can have a
performance impact that is obvious to users and detrimental to their experience with an application. The amount of
time a single operation takes varies according to the operation and particularly the amount of data it involves. For
instance, a SQL INSERT statement that only adds a single row to the database takes less time than a SELECT statement
that retrieves thousands of rows of data. However, when you’re using synchronous execution to perform multiple
operations, the operations are usually strung together. Even if the time each single operation takes is very short, the
application is frozen until all the synchronous operations finish. As a result, the cumulative time of multiple operations
strung together may be enough to stall your application.
Use asynchronous operations as a standard approach, especially with operations that involve large numbers of rows.
There is a technique for dividing up the processing of large sets of SELECT statement results, described in “Retrieving
SELECT results in parts” on page 741. However, this technique can only be used in asynchronous execution mode.
Only use synchronous operations when you can’t achieve certain functionality using asynchronous programming,
when you’ve considered the performance trade-off that your application’s users will face, and when you’ve tested your
application so that you know how your application’s performance is affected. Using asynchronous execution can
involve more complex coding. However, remember that you only have to write the code once, but the application’s
users have to use it repeatedly, fast or slow.
In many cases, by using a separate SQLStatement instance for each SQL statement to be executed, multiple SQL
operations can be queued up at one time, which makes asynchronous code like synchronous code in terms of how the
code is written. For more information, see “Understanding the asynchronous execution model” on page 756.
Last updated 6/6/2012
775