Justin Willey wrote:
Great news! Thanks for the update Justin.

Happy New Year!
greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/

From the attached SCJView log, it does not seem to be set to
be using just TCPIP there. It is still starting up all protocols
(with TCP/IP the last one tried -- and that needing to do a
broadcast to find a local server from some unknown reason).

You also seem to be starting this with a non-default port (2624)
as witnessed by this entry:

Found database server at address 192.168.2.21:2624


Setting LINKS=TCPIP should speed this up a little, since
it will bypass all initialization of and connection attempts over
SPX and namedpipes

... but ...

I do not understand why

1 - it just does not connect over shared memory,
2 - and it fails to connect over namedpipes
or
3 - or even why it needs to broadcast to find the server
when it is obviously on the same machine's IP address.

We sometimes see this happening with Citrix and/or MS Terminal
Services. If running that way then you will need to pick a real
protocol [so picking TCPIP is obviously your protocol of choice
in that case]

As such this should work even faster if you specify just

LINKS=TCPIP{HOST=localhost}
or
LINKS=TCPIP{HOST=192.168.2.21}
or even
LINKS=TCPIP{HOST=<paste_your_local_machine_name_he re>}

Even better

LINKS=TCPIP{DOBROADCAST=NONE;HOST=localhost;PORT=2 624}

which should just connect instantly.

But since that is quite complex if you are not using Terminal Services
(or Citrix) you might want to analyze this from the server side. [add
-z -o diagnose_server.txt to the server commandline to see how the
server is starting up].

----- further ----
Since you seem to be asking about Sybase Central if you are using
connection profiles created with an older version of the product
[or is Sybase Central, itself, was somehow not upgraded] you
may also be exposed to this bug

========== (Build #3129 - Engineering Case #392017) ==========
If a shared connection profile was created, it was not saved if
Sybase Central
terminated abnormally after the connection profile dialog is
closed. Private
connection profiles were saved properly. This has now been
fixed.

If this sounds like your issue, you probably need to

1- Upgrade/EBF the version of Sybase Central
2 - Drop the connection profile [or remove the server from the
asasrv.ini file]
3 - Reconnect/recreate the connection profile

A good alternative is to set an ODBC data source and specify the DSN
in your connection profile.



"P Merritt" <pmerritt (AT) transcendonline (DOT) com> wrote

Thanks Nick.. Your suggestions are REALLY helpful
- since I'm often accessing a service on another machine, I usually don't
use Shared Memory
- I had several services running; different ones for different databases;
hence I needed different ports. I think that was because I was having
problems getting ODBC on one machine to access different databases running
on the same database server (on another machine).
I guess I've gotten that straightened out and am now able run all the
databases off the same server (how many is too many? or is that how many
users too many?)
- I'd been thinking that using a non-default port could make the server less
vulnerable to hacking .. is that just wrong headed ?
- I discovered that I, like Justin Willey, did have ODBC tracing
running..and once I turned it off, all was well (I'd not seen his message
before)


"Nick Elson" <no_span_nicelson (AT) sybase (DOT) com> wrote