Running a SQL Anywhere database server on cloned systems

[jose_at_sap]

There are situations where you may want to clone an existing system and deploy that image to other computers.  A couple examples include training and mass deployment.  Applications that embed the SQL Anywhere database server may run into problems because if you use the TCP/IP protocol, the database server name must be unique in your network.  What happens is that your "master" computer image works as expected, but when you start a "cloned" system the database server cannot launch because the same server name is already in use.

If your application can connect to the database server using shared memory, then you have a couple of options:

1. Use the personal database server (dbeng16), specifically provided for single-user, single-computer use; or
2. Use the network database server (dbsrv16) and launch it with the "-x none" option to disable the TCP/IP network protocol

The command line looks like one of these:

dbeng16.exe -n MyServerName MyDatabase.db

dbsrv16.exe -n MyServerName -x none MyDatabase.db

Both of these commands start the database server MyServerName and load the database file MyDatabase.db.  The difference is that the personal database server (dbeng16) has some limitations (e.g. 10 simultaneous connections, max 4 cores per one CPU).  A complete list of those limitations is here: http://dcx.sybase.com/sa160/en/dbadmin/da-running-database-server-differences.html.  Use the network database server (dbsrv16) if you need to get around them.

If your application needs to connect using the TCP/IP network protocol (for example, a Java application using the jConnect JDBC driver), then you have the same two options, but with some differences:

1. Use the personal database server (dbeng16) and launch it with the "-x tcpip" option to enable the TCP/IP network protocol; or
2. Use the network database server (dbsrv16), but with specific network protocol options to control how other computers connect to the database

The command line for the personal database server looks like this:

dbeng16.exe -n MyServerName -x tcpip MyDatabase.db

The same limitations stated above apply, so if you need to use the network database server, you can choose from a couple different options:

One method to get around the unique server name problem is to start the database server using environment variables, such as the computer's name.  The command line looks like this:

dbsrv16.exe -n MyServer-%COMPUTERNAME% -x tcpip MyDatabase.db

This starts a network database server called "MyServer-%COMPUTERNAME%", where computer name is your machine's name in the network and it's unique.

While this approach works in many instances, it does have a couple of drawbacks:

1. The environment variable %COMPUTERNAME% must be properly defined.  It usually is, but it can be modified by an admin user.
2. If you try to connect to the database using ODBC, you may not be able to find the database server.  Using %COMPUTERNAME% in command-line utilites will work, but the ODBC Administrator has problems with it, so it interprets %COMPUTERNAME% as those exact characters (it doesn't replace them with the value of the environment variable).

This method, however, will allow other computers to connect to the database, provided that they know the database server name or IP address.

A second approach is to use the "LocalOnly=YES" network protocol option when starting the database server, like this:

dbsrv16.exe -n MyServer -x tcpip(LocalOnly=YES) MyDatabase.db

This starts a network database server, but restricts connections to the local computer.  In essence, it's the same behaviour as starting the personal database server, but without its limitations.

Whichever method you choose depends on what you want to accomplish, but in the end the end-result is pretty much the same and your cloned systems will have no problem starting the database server.