Scav wrote:
And why in the world does the setup
program for a runtime client install an instance of DB2 on a client
machine???
Common misconception. An instance is *NOT* a server. It is an
*environment*. It is an environment under which applications may run DB2
applications. It just so happens that one of the biggest and most
pervasive DB2 applications might just be the DB2 server itself.
This environment tells applications where to load DB2 libraries (DLLs on
Windows), and tells DB2 where to find its own configuration, both for
reading and for updating. This configuration includes local databases for
the server, and remote nodes and databases for client applications. This
allows applications to simply connect to "mydb" and not care whether the
database named "mydb" is local or remote, or even if it's on a mainframe,
or if it's anything else supported by the DB2 Client (I think it includes
Informix and maybe even Cloudscape, but can't recall offhand for sure).
The client configuration, which exists even in the servers, will handle
that abstraction.
So why are there instances? To be able to have multiple such configurations
on a single machine. Not quite so useful on single-user machines, but
still can be useful when you want to better isolate two apps such that they
don't accidentally connect to the wrong database by having more than one
database cataloged. Or if you're just testing your app - you can have your
production configuration in one instance, and a test configuration in
another, both with the same database name cataloged, but connecting to
different databases at the other end (either different nodes, or different
real database names, or both) - you just have to switch between instances
when you go to test, and back when you need to work with the production
database.
Not everyone needs them, but those who do can find it invaluable.
