Eitan,
> what I though was:
> Security - for this connection I use 'dbsrv7.exe -x "tcpip{.... and any
> client on the same net can try to access my db. because all the database
> access is done on the same server I thought it will be good to access
> directly to the database without the ability to let clients to access the
> database.
Yes, for you are running tcpip, it will be possible to connect from other stations. It
seems that there is no possibility to tell the server to only accept
local clients, but it would be best if you ask this question on sybase usenet forum.
If found one thing: there is a parameter -sb 0 that you can set on
server startup. This will disable the server's reaction to broadcast. This means, that
a client has to use DoBroadCast=No and to specifiy the server with
Host=ServerHostName. That is better than nothing. What I also found is that ASA is C2
certified. With this, it should be possible to do what you want, but
maybe you need to ask Sybase directly for that. You also can encrypt database
communication, so if you keep the database password as a secret, no one will be
able to access the database. It would be nice if you could access the server by shared
memory (-x SharedMemory), but since jConnect is a 100% pure Java
driver, it is able to connect by shared memory (and this is exactly what that Oracle
Thin driver does, and some other "two-tier"-drivers).
> performance - I though maybe direct access to the database will be more
> good.
> did I messed with this JDBC issue?
Yes, sure this would be faster, but you should think of all other performance tasks
first, e. g. larger network buffers, larger packet size etc. We could not
find any REAL performance problems with JDBC (jConnect) in comparision with ODBC,
since jConnect works on top of the Java VM's TCP stack, which in turn uses
the same OS APIs to communicate as ODBC does, so for the problem is the wire and not
the machine, there should be no real performance problems with that.
