I have installed SQLAnywhere10 on an Intel iMac but have not
been able to create a database. I keep getting the
following error:
Could not connect to the database
Unable to start database server
[Sybase][ODBC Driver][SQL Anywhere]Unable to start database
server
Error code= -80
SQL state=08001

Any suggestions would be greatly appreciated

Are you able to start the engine without a database (for example, by
running 'dbeng10 -n my_engine')? If not, what error message do you get?

Are you trying to create the database from a command line or from within
Sybase Central?

Ray

wasabi wrote:

Thanks for asking. Yes, I am able to start the database
with dbeng10
I was trying to create it from within Sybase Central
What I actually want to do is convert a DB I have in
SQLAnyhwhere9 on a ppc eMac
so that it will run in SQLAnywhere10 on the iMac. I manage
to unload the old database. If you have command line
instructions (or where to find them) for creating the new
database I would also appreciate those since I do not care
how I
create the database.
The screen at which I get the initial error in Sybase
Central is the one that asks "Do
you want to create a database on this computer or on another
computer" There is a
tick that states "Create a database on this computer (A new
local server will be started automatilly). When the next
button is clicked the error appears.

Wasabi,

To create a new empty ASA10 database, the easiest way is to let the Wizard
guide you through the different steps in Sybase Central: Select "Create
database" from the tools to start this wizard.

Then open ISQL, connecting to the newly genarated database, and run the
rebuild.sql file that the unload has generated.

Frank

On Wed, 24 Oct 2007 20:06:59 +0200, <wasabi> wrote:

Are you running the Developer Edition? Currently, a limitation of the
Developer Edition on Mac OS X is that it is impossible to auto-start an
engine from the Administration Tools, which is what Sybase Central will
attempt to do when you try to create an engine. You can get around this
by pre-starting an engine from the command line or from DBLauncher and
giving it the engine name 'dbinit_engine' (e.g., 'dbeng10 -n
dbinit_engine'). Sybase Central will then connect to this engine and
will be able to create a new database.

Alternatively, you can create a database from the command line by
dbinit, e.g., 'dbinit mydb.db'. Running 'dbinit -?' will display the
command line options dbinit accepts. These options are also documented
in our documentation.

Ray

wasabi wrote:

Thank you Ray for the suggestion. Just a note - in order to
get a list of the
available options the command is 'dbinit -h' and not 'dbinit
-?' Unfortunately
I just tried 'dbinit mydb.db' to see if it would work and I
still could not start
the server. This is what I got:
dbinit /tmp/mydb.db
SQL Anywhere Inistialization Utility Version 10.0.1.3419
SQL error (-80) -- Unable to start database server
Database "/tmp/mydb.db" not created

I also tried the 'dbeng10 -n dbinit_engine' . This started
fine. However, your
suggestion that Sybase Central will connect to this server
made no difference.
I still got the SQL error (-80).

Thank you for the above tip. However, the error 'cannot
connect to server' is
generated when I initially wanted to create the database
inside Sybase Central.
Trying dbinit and dbeng10 also resulted in the same SQL
(-80) error.

I tried isql but again since I cannot connect to the server
I cannot
run the rebuild.sql.

Your being unable to run dbinit from the command line is definitely curious.

Could you provide me with some information about your configuration?
What version of Mac OS X are you running?
Are you running the Developer Edition of SQL Anywhere, the Evaluation
Edition, or the full version?
Did you use the GUI installer ("Install SQL Anywhere.app") or the
command line installer (the setup script) to install SQL Anywhere? If
you used the command line installer, what installation directory did you
choose?

One thing to try is to start an engine with the command line options "-z
-n dbinit_engine" in one terminal window and then try running dbinit
from another terminal window. Does the engine's console show connection
attempts from dbinit?

wasabi wrote:

We are running Mac OS X 10.4.1

We are running the Developer Edition

I used the Gui Installer and it installed SQLAnywhere10 in
the /Applications directory

Wow. I just tried this and got the following:
from the dbeng10 screen:
Starting database "utility_db" (utility_db) at Thu Oct 25
2007 10:29
Database "utility_db" (utility_db) started at Thu Oct 25
2007 10:29
Connection ID 1: "DBA" connected to database "utility_db"
from SQL Anywhere 10.0.1 (3419) client over SharedMemory
Connection ID 1: AppInfo is
IP=129.97.51.165;HOST=imac001.student.cs.uwaterloo .ca;OS='Darwin
8.10.1
i386';PID=0x348;THREAD=0xa000d000;VERSION=10.0.1.3 419;API=DBLIB;
TIMEZONEADJUSTMENT=-240
Connection ID 1: Server character set conversion is enabled,
but not required
using character set "ISO_8859-1:1987"
Starting database "a_dbinit" (/tmp/mydb.db) at Thu Oct 25
2007 10:29
Transaction log: mydb.log
Starting checkpoint of "a_dbinit" (mydb.db) at Thu Oct 25
2007 10:29
Finished checkpoint of "a_dbinit" (mydb.db) at Thu Oct 25
2007 10:29
Database "a_dbinit" (mydb.db) started at Thu Oct 25 2007
10:29
Starting checkpoint of "a_dbinit" (mydb.db) at Thu Oct 25
2007 10:29
Finished checkpoint of "a_dbinit" (mydb.db) at Thu Oct 25
2007 10:29
Database "a_dbinit" (mydb.db) stopped at Thu Oct 25 2007
10:29
Connection ID 1: "DBA" disconnected from database
"utility_db"
Database "utility_db" (utility_db) stopped at Thu Oct 25
2007 10:29

From the dbinit screen:
SQL Anywhere Initialization Utility Version 10.0.1.3419
CHAR collation sequence: ISO1LATIN1(CaseSensitivity=Ignore)
CHAR character set encoding: ISO_8859-1:1987
NCHAR collation sequence:
UCA(CaseSensitivity=Ignore;AccentSensitivity=Ignor e;PunctuationSensitivity=Primary)
NCHAR character set encoding: UTF-8
Creating system tables
Creating system views
Setting option values
Database "/tmp/mydb.db" created successfully

and we see:
-r--r--r-- 1 root wheel 2076672 Oct 25 10:29
/tmp/mydb.db

So it created mydb.db
And in dblauncher I get:
2 logical processor(s) on 1 physical processor(s) detected.
This server is licensed to:
Developer Edition
Restricted Use
Running Darwin 8.10.1 Darwin Kernel Version 8.10.1: Wed May
23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 on
X86
Server built for X86 processor architecture
8192K of memory used for caching
Minimum cache size: 8192K, maximum cache size: 940032K
Using a maximum page size of 4096 bytes
Starting database "mydb"
(/Applications/SQLAnywhere10/mydb.db) at Thu Oct 25 2007
10:52
Transaction log: mydb.log
Starting checkpoint of "mydb" (mydb.db) at Thu Oct 25 2007
10:52
Finished checkpoint of "mydb" (mydb.db) at Thu Oct 25 2007
10:52
Database "mydb" (mydb.db) started at Thu Oct 25 2007 10:52
Database server started at Thu Oct 25 2007 10:52
Trying to start SharedMemory link ...
SharedMemory link started successfully
Trying to start TDS (TCPIP) link ...
Unable to start on default port; starting on port 49152
instead
TDS (TCPIP) link started successfully
Now accepting requests

So which command line interface do I use to rebuild the
database. I have the
unloaded data directory from the SQLAnywhere 9 database?

If you've generated a reload.sql file on the PowerPC Mac, you can apply
it to the new database from the command line using something like
'dbisqlc -c "uid=<uid>;pwd=<pwd>" reload.sql', assuming the database is
already running.

I tried to reproduce your problem with running dbinit from the command
line on a Mac OS X 10.4.10 machine, and I couldn't. I wonder if dbspawn
works for you (e.g., "dbspawn dbeng10 mydb.db"). If this fails but you
can start the database directly and connect to it, it would suggest
something in the auto-starting gear is malfunctioning.

Judging from the hostname in the trace you've posted, am I correct in
assuming that you are running SQL Anywhere on one of the machines in the
Mac labs at UW? Are those machines locked down in any way, or do you
have full access to everything?

It might be worthwhile to check the system log to see if anything
interesting was logged at the time of the failure. You can do this by
running Console.app (in /Applications/Utilities), clicking on the "Logs"
button in the toolbar, and checking in the system.log and console.log files.

Ray

wasabi wrote: