[Info-Ingres] The never ending database name, JDBC and other stories.

[martin.bowes at ctsu.ox.ac.uk]

Hi Paul
> 
> It's not intentional that dbname be recursive. If that's implied
> somewhere in the manuals then that's probably a doc bug.

I cant recall seeing anything in the manuals that suggest this should be 
recursive. But in a casual inspection of a few there is nothing to say it 
shouldn't be. Although I would say there are some things that just 
shouldn't need to be documented; things like:
"Do not attempt to stop chainsaw blade by hand or with genitals."

> 
>     Are all your machines the same architecture? All either 64- or
>     32-bit and the same endian- ness? 
Nope! We have a few cases where things work where the hosts are 
identical architecture. But in the cases that have problems we are 
crossing from 32 to 64 bits. I think big ended on both.

I've seen a case with 
>     sql vnode1::vnode2::db
> 
>     where vnode1 points from Solaris (Sparc) to Linux, and vnode2
>     points from Linux to Solaris where db lives. It "sorta" worked in
>     the sense of a connection is made but values got garbled. We
>     consulted Development and the response was
> 
>     "Multiple vnodes are not supported and I'm surprised it was
>     possible to establish a connection.

Yeah, I would have bet London to a brick the syntax would have been 
rejected on the spot. I suppose the guys doing the syntax check hadn't 
read the chainsaw manual.

The heterogenous support info
>     which flows across the net is not propogated to local IPC
>     communications, and there is a local (loopbacked) IPC on the Linux
>     box in this case. The result is that one of the connections does
>     not have the info it needs to handle heterogenous data.
> 
>     Even if it did work, it would be very inefficient since there is
>     an unnecessary local IPC on the Linux box and duplicate het/net
>     processing in each network connection. Using a single
>     vnode/network connection is preferred.
My understanding is that the multiple vnodes - using a mixture of 
Installation passwords and account authentications was done as  hack 
to 'make it work' rather than a deliberate design. I suspect this may 
have been due to initial problems with account authentication with 
shadow password files and/or mixtures of password files.

 If the two Solaris boxes
>     can't communicate, using Bridge is more efficient: no local IPC in
>     the middle, het/net processing is end-to-end and independent of
>     intermediate hosts (in this case het/net would most likely be
>     avoided since the two Solaris installations could be homogenous)."
> 
>     So in other words if you need to go from A to B go direct, if you
>     need to go via C then use the bridge server that's what it's for.

Ooh thats interesting. I always thought the Bridge Server was only to be 
used when connecting to non-Ingres databases.
Thats a whole new manual to read!
> 
>     I can post a guide to setting up the bridge server if anyone's
>     interested.
Tah!
 
Marty