The default user ID for demo.db and newly created databases is DBA and the default password is sql. The user ID is case-insensitive and the password is case-sensitive. You should change the password before deploying the
For more information about default user IDs and passwords, see DBA authority.
The connection parameters required to connect to a database vary depending on the location of the application relative to
the database server. The following connection scenarios assume that there is no communication encryption and there is only
one database running on a database server.
In the following examples, you connect to the SQL Anywhere sample database, %SQLANYSAMP12%\demo.db using Interactive SQL.
Example 1: The database server is not running, and the database file is installed on the same computer as the application
You must provide the correct user ID, password, connection and database file parameters for the database file. You may
also need to specify the database server name. To connect to the database, run a command similar to the following:
Example 2: The application and the database server are running on the same computer
You must provide the correct user ID and password. It is also recommended that you provide the database server name to
avoid connecting to the wrong database server. To connect to the database, run a command similar to the following:
dbisql -c "UID=DBA;PWD=sql;Server=demo"
Example 3: The application and database server are running on different computers
You must provide the correct user ID, password, database server name, and HOST connection parameters. To connect to the
database, run a command similar to the following:
Databases created with SQL Anywhere 9.0.1 or later include the SYSHISTORY system view. The rows in this view that reflect
INIT and UPDATE operations give information about when, and with what version, the database was created and upgraded. See
SYSHISTORY system view.
Yes, you can install multiple major versions of SQL Anywhere on the same computer. For example, SQL Anywhere 9.0.2, 10.0.1,
11.0.1, and 12.0.1 can all be installed and run independently.
However, you must use caution when starting a SQL Anywhere executable that has the same name in multiple versions (for example,
dbisql or dbinit) to ensure that you are starting the correct version of the application. You can either specify the full
absolute path using environment variables such as SQLANY12, or ensure the version of SQL Anywhere you want is specified first
in your path.
For SQL Anywhere 10 and earlier for Windows using the SQL Anywhere installer
Yes, you can install multiple copies of the same version of SQL Anywhere on the same computer. However, the SQL Anywhere
installation program registers some drivers and components in the Windows registry, and there is only one copy of the registry.
As a result, the ODBC and OLE DB drivers from the most recent installation are used. Similarly, there is only one set of Start menu shortcuts. They point to the most recently installed copy of SQL Anywhere.
For SQL Anywhere 11 and later for Windows using the SQL Anywhere installer
No, you can only install a single copy of SQL Anywhere 11 on a computer.
For SQL Anywhere 12 and earlier for Linux or Unix using the SQL Anywhere installer
Yes, you can install multiple versions in different locations. However, on Linux, if you choose to install application
menu items, each user can only have one set of application menu items. They point to the most recently installed copy of SQL
For deployed embedded database applications
Yes, deployed embedded database applications that include SQL Anywhere can be deployed with other SQL Anywhere installations
on the same computer.
On Windows operating systems, the ODBC and OLE DB driver names in the registry should include the name of the application
in which they are embedded. For example, the ODBC driver name SQL Anywhere 12 should be renamed application-nameSQL Anywhere 12. See Database and application deployment and ODBC driver configuration.
You should run multiple databases on a single database server because this configuration optimizes the use of computer resources.
Having multiple database servers running on the same computer may result in a competition for resources, and (with dynamic
cache resizing) this configuration may result in degraded or unpredictable performance. Degraded or unpredictable performance
may be acceptable if you need to stop one database server for maintenance without affecting the others, or if you need to
isolate errors to a single database server.
SQL Anywhere performs best when the database is created with the same major version as the database server. Rebuild the database
if you are experiencing performance problems and no longer need to run the database on earlier versions of SQL Anywhere. See
Database rebuilds and Performance monitoring and diagnostic tools.
SQL Anywhere developers strive to ensure that applications continue to work after an upgrade. However, your application may
be affected by behavior changes and the removal of previously supported features.
To determine if behavior changes have been made to your version of SQL Anywhere, or if features have been removed or deprecated,
select the section relevant to your version of SQL Anywhere. See SQL Anywhere 12 - Changes and Upgrading.
If your JDBC applications do not work after applying an EBF, it is likely because you had either Interactive SQL, Sybase Central,
the fast launchers, or other JDBC applications running when the EBF was applied. Shutting down all JDBC-based applications
and reapplying the EBF may resolve the problem. See Ensure JDBC applications are not running when applying an EBF.
For descriptions of the different licensing options for SQL Anywhere 10 and later, including examples that show you how to
apply your license, see SQL Anywhere Licensing (http://www.sybase.com/detail?id=1056242).
The size of the database that can be supported by SQL Anywhere is dependent on the memory, CPU, and disk drive capacity of
the computer on which SQL Anywhere is installed. See SQL Anywhere size and number limitations.
No. The OUTPUT statement can only be executed in Interactive SQL and cannot be used within a stored procedure. Use the UNLOAD
statement within your stored procedure to save the result set generated by a SQL statement to a text file. If you use the
UNLOAD statement in your stored procedure, information is unloaded from the database server and not from the client computer
from which the statement was executed. See UNLOAD statement.