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

[Paul Mason]

On 18/04/07, martin.bowes at ctsu.ox.ac.uk <martin.bowes at ctsu.ox.ac.uk> wrote:
>
>  Hi Everyone,
>
>  A funny thing happened the other day when I was looking at why a JDBC
> connection string was failing...
>
>  I can now imagine this conversation had occurred at some point ..
> Somene stated:
>             'A fully qualified database name is: [vnode::]dbname[/class]'
> Q. Cool, but whats a dbname?
> A. Oh that's just a [vnode::]dbname[/class]
>
> So put that togethor and you get: vnode1::vnode2::dbname
>
>  Q. Yeah, but whats a dname?
> A. Oh that's just a [vnode::]dbname[/class]
>
>  So put that togethor and you get: vnode1::vnode2::vnode3::dbname
>
>  etc...Thank God they didn't attempt to graft /class1, /class2... into the
> mess.
>


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

The staggering thing is that it works, sorta...
>


"sorta" being the operative word.

As long as all the authorisations and network connections can be verified
> the connection to the final database is cool.
>

Are all your machines the same architecture? All either 64- or 32-bit and
the same endian-ness? 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.  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.  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.

I can post a guide to setting up the bridge server if anyone's interested.

-- 
Paul Mason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.kettleriverconsulting.com/mailman/private/info-ingres/attachments/20070418/8b39d004/attachment.html