on 2013 Oct 29 4:02 AM
Dear Sir,
I had a normally functioning database running normally under windows 2008 R2 64 bits.
Suddenly yesterday during working time all users were unable to connect to database.
Windows connection and any others applications were still functioning properly only sybase database connections were affected. we try restarting the system with no results.
the only way that i was able to connect user is by creating a registry file on each pc indicating the TCP/IP address of the windows server and the port of the running database.
Could you please advise as it is a very urgent matter affecting my business.
Regards,
Something must have changed on your network so that the clients can no longer find the database engine.
To give you definite advice we would need to know rather more about the situation
If you are using ODBC, the simplest way to see what is going on is to start logging connection information to a file - see the Advanced tab of the wizard.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for the extra information - I've changed the tags on your question to reflect that.
Something about your network means that the clients can no longer find the server without the IP address and port. What port is the server listening on - the standard one?
Try logging the connection information as I explained - that may show you where the problem is.
Also you may find this documentation helpful : http://dcx.sybase.com/index.html#1001/en/dbdaen10/da-network.html
It is for version 10.0.1 but the principles still apply.
Dear Sir ,
this is the log file of connection:
Fri Dec 27 2013 10:50 Application information: "HOST=THAER-PC;OS=Windows NT 20.0 (Service Pack 1);PID=0x15d4;THREAD=0x1b80;EXE=C:\\Program Files (x86)\\Sybase\\PowerBuilder 7.0\\pb70.exe;VERSION=8.0.0.2213;API=ODBC;TIMEZONEADJUSTMENT=120" Attempting to connect using: UID=dba;PWD=***;ENG=spac11;CON=SQL_DBC_4f0dac0;ASTOP=YES;INT=NO;DBG=YES;LOG=c:\\spac\\inf;DMRF=NO;LINKS=SharedMemory,TCPIP{};COMP=NO Attempting to connect to a running server... Attempting SharedMemory connection (no asasrv.ini cached address) Failed to connect over SharedMemory Attempting TCPIP connection (no asasrv.ini cached address) Failed to connect over TCPIP Not attempting to autostart server Cannot connect to server
I. 12/27 11:07:57. Sybase Adaptive Server Anywhere Network Server Version 8.0.0.2213 I. 12/27 11:07:57. Copyright © 1989-2001 Sybase, Inc. Portions Copyright © 2001, iAnywhere Solutions, Inc. I. 12/27 11:07:57. All rights reserved. All unpublished rights reserved. I. 12/27 11:07:57. I. 12/27 11:07:57. This software contains confidential and trade secret information of I. 12/27 11:07:57. iAnywhere Solutions, Inc. Use, duplication or disclosure of the software and I. 12/27 11:07:57. documentation by the U.S. Government is subject to restrictions set forth in a I. 12/27 11:07:57. license agreement between the Government and iAnywhere Solutions, Inc. or I. 12/27 11:07:57. other written agreement specifying the Government's rights to use the I. 12/27 11:07:57. software and any applicable FAR provisions, for example, FAR 52.227-19. I. 12/27 11:07:57. I. 12/27 11:07:57. Sybase, Inc., 6475 Christie Avenue, Emeryville, CA 94608, USA I. 12/27 11:07:57. Concurrent Seat model. Access to the server is limited to 25 concurrent seat(s). I. 12/27 11:07:57. This server is licensed to: I. 12/27 11:07:57. La Libanaise Des Jeux I. 12/27 11:07:57. La Libanaise Des Jeux I. 12/27 11:07:57. 1048576K of memory used for caching I. 12/27 11:07:57. Minimum cache size: 1048576K, maximum cache size: 1048576K I. 12/27 11:07:57. Using a maximum page size of 8192 bytes I. 12/27 11:07:57. Starting database "spac11" (e:\\itm03\\spac11\\spac11.db) at Fri Dec 27 2013 11:07 I. 12/27 11:07:57. Database file "e:\\itm03\\spac11\\spac11.db" consists of 62 disk fragments I. 12/27 11:07:57. Transaction log: E:\\itm03\\spac11\\spac11.log I. 12/27 11:07:57. Starting checkpoint of "spac11" (spac11.db) at Fri Dec 27 2013 11:07 I. 12/27 11:07:57. Finished checkpoint of "spac11" (spac11.db) at Fri Dec 27 2013 11:07 I. 12/27 11:07:57. Database "spac11" (spac11.db) started at Fri Dec 27 2013 11:07 I. 12/27 11:07:57. Database server started at Fri Dec 27 2013 11:07 I. 12/27 11:07:57. Trying to start SharedMemory link ... I. 12/27 11:07:57. SharedMemory link started successfully I. 12/27 11:07:57. Trying to start NamedPipes link ... I. 12/27 11:07:57. NamedPipes link started successfully I. 12/27 11:07:57. Trying to start TCPIP link ... I. 12/27 11:07:57. Unable to start on default port; starting on port 49160 instead I. 12/27 11:08:02. TCPIP link started successfully I. 12/27 11:08:02. Trying to start SPX link ... I. 12/27 11:08:02. SPX communication link not started I. 12/27 11:08:02. Now accepting requests
...Unable to start on default port; starting on port 49160 instead
This may be the cause of your problems: Some other application on the machine the database server is running on has already occupied the default port 2638 - possibly a different SQL Anywhere database engine?
AFAIK, clients will usually only connect via TCP/IP to servers running on the default port unless you add the "PORT=49160" network communication parameter to your LINKS connection parameter.
If you do not want to change the ODBC settings of your client machines, I would think you should try to find out what other application is occupying the default TCP/IP port, and make sure the current database server does again use that port.
Volker: Clients can automatically connect to servers that are running on ports other than 2638 if they are on the same subnet (or dbns is being used) and the client has not specified the port and the client has specified server name. This is done through the UDP broadcast mechanism that is built into the client/server protocol. I.e. the client will send a broadcast on UDP port 2638 (which all servers will listen to, even when there is more than one server per host) and the server with the specified name will respond back to the client (also using UDP packet) to tell the client on which host the server resides.
@Mark: Thanks for the explanation, and yes, I had the impression the UDP broadcasts would be missing in my hints:(
So, given server and client are on the same subnet, and the client does specify a server name and does not specify a port (as it seems here), they should be able to connect - unless a firewall or some other tool will prevent UDP broadcasts?
(FWIW, 8.0.0.2213 seems to be a very old version, even on the v8 scale.)
User | Count |
---|---|
74 | |
10 | |
9 | |
7 | |
6 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.