Re: Accessing another DB with Logging

'yvind Gjerstad wrote: > > "Art S. Kagel" <kagel@bloomberg.com> writes: > > > You could also use separate connections one for each database. I have > > not yet tried to create and ESQL/C function set to set and switch from > > one connection to another but it works great in ESQL/C alone. Indeed, > > I have found that the rewitten programs using separate connections for > > accessing each remote database actually runs faster than accessing > > those databases from one connection as remote selects. > > Yes, but be aware that you then of course loose transactional integrity > between the two databases (which would be hard to get with one of the > dabases running without logging anyway). Correct but for this application, copying a table from an unlogged database to another logged one, one does not need transaction control on the source table only on the target table. > The speedups are probably due to the databases not having to exchange > transaction information. Perhaps, but I am also experiencing programs which fetch from a multiple remote servers which once did so through synonyms in a local database or in one of the remote servers or which read from remote tables directly (ie using the full database@server:table syntax) which do not perform any transactions (ie read rows from remote and write flat files or output to user terminals) and which are running faster by keeping local and multiple remote accesses segregated to their own connections (one per remote server). I think that the internal library code needed to swap buffers and handle switching contexts implicitely when alternating reading from a local and one or more remote cursors contains more overhead than the explicit context handling code in the library for SET CONNECTION TO .... Just guessing of course, but this is what we are seeing. Art S. Kagel