I am struggling to find how to access the server console on Windows Server 2008, and was hoping someone might be able to help? By this I am referring to the message window accessed by clicking on the lightning strike which appears in the start menu by the clock. In this case it is a network server which I have launched by using an auto-starting service created in Sybase Central. Is this message window accessible from anywhere else, as it is very useful to point a client at to check the database service has started up correctly. I'm running SQLAnywhere 11.0.1.2427. Thanks |
Have a look at DBCONSOLE (->Sybase DCX). This utility displays the messages that would be shown in the info window of the database engine (if MS hadn't decided services should not interact with the desktop anymore). Minor drawback: you'll have to establish a connection to a database started by the engine. 2
For the record, Vista and later OSs do not allow services to interact with the desktop so there will be no lightning bolt icon in the systray and there is no way to see the server's application window because, well, there isn't one. |
A further (and very common) approach is to let the database engine write the server messages to a log file (which is a plain text file, not to be mistaken with the transaction log). You can use the -o engine command option for this (and its variants like -oe for startup errors and the like). Then for trouble-shooting, you (or your customer) just have to open the file. It's particular helpful when diagnosing problems with server startup or shutdown (where the DBCONSOLE is less helpful for obvious reasons...) and often asked for by technical support. We use this and it's a great option. But keep an eye on the size of the file. Whenever we have cause to stop the server, we make sure we move the existing file into an archive and let it start over. Comment Text Removed
@Carol: I agree:) Then I would recommend to use option -os MaxSize (i.e. automatically renaming the log file when is reaches the maximum size and creating a new one), or option -on MaxSize (which works similarily but keeps just one old log file). |
If you are willing to use web services and can start the server with the "-xs http" server switch to start the SQL Anywhere built-in HTTP server, then you could do the following to view the console messages in a browser: 1) Create a web service in your database that accepts requests:
2) Define the sp_console_messages() procedure:
3) Add "-xs http" to your server start line (if you haven't done this already). E.g.
4) Use your browser to view the console log by browsing to:
Note that the messages come out in reverse order - this is due to the "desc" in the order by clause of the list() expression in the sp_console_messages procedure. I did this so the most recent message would be displayed at the top (so you don't have to scroll down all the time to see what has recently happened). If you don't like this, simply replace "desc" with "asc" (or remove "desc" completely). You can do lots of interesting things using similar methods. E.g. get a list of server properties (call sa_eng_properties), connection properties (call sa_conn_properties), etc. To be secure, you can either add "AUTHORIZATION ON" to your service definition to require that the dba username/password is specified in order to get the console messages, or add "SECURE ON" (and add appropriate certificates to the "-xs https" server command line) to require that a secure connection is used, or BOTH (which I would recommend!). |
As a variant of Mark's webservice approach, you also can use the server properties "Messages", "MaxMessage" and the like to list the messages in a usual SQL result set or display them in DBISQL. Here's the source of a small helper procedure we do use to display such messages in DBISQL's status area:
If applicable, you can grant even non-DBA users the right to execute this procedure to llok for server messages. |
Thanks everyone - it's good to know why the console doesn't appear any more, and I had never seen the View Server Messages and Executed SQL which is probably good enough for my purposes. The other answers could all be useful in the future, so thanks again! |