On 18 Jan 2001, at 6:28, Brad Pepers wrote:

Organization: Linux Canada Inc.
To: ib-support@egroups.com
From: Brad Pepers <brad@...>
Date sent: Thu, 18 Jan 2001 06:28:24 -0700
Send reply to: ib-support@egroups.com
Subject: [ib-support] isc4.gdb database

> I was wondering about the rational behind the isc4.gdb database for
> storing the user names. Its seems to complicate things a fair bit and
> would seem easier to me if the user information for a database was
> stored inside the database's own .gdb file. Perhaps its just because
> I'm used to it working that way in Sybase SQL Anywhere but to me this
> seems easier. The separate user database buys you easier
> configuration for a lot of databases but at some costs that don't
> really seem worth the end result. Am I missing something here?

The rational, is probably very simple, if an organization has 40
databases, the the poor DBA doesn't have to spend all of their time
doing user maintenance, because all of the users are in one location.

Having said that, I think any DBA that sets up 40 databases, deserves
to spend all of their time adding users to databases. Databases by
their very nature are intended to store everything in one place, and
splitting them up causes no end of grief, because there will always
be a table in database-1 that needs to be accessed from database-2.

There is an exception however, you should always maintain a
completely seperate production and test version of the database,
preferably maintained on seperate servers. This way developers can
not FUBAR the production database during development and debugging.

I think the best solution, is to make this database dependant, then
those people who have a reason to use isc4.gdb can, and those who
would rather embed the tables within the main .gdb could do it that
way. The best way to accomplish this, is to ship a script to define
these tables, that can be fed into isql, to create them in your .gdb.
The server when it opens the database would look for these tables,
if they exist then it uses the internal copy. If they do not exist,
then it opens isc4.gdb and uses that copy. Yes that would meain that
if you had 3 databases, one could use it's own users tables, while
the other two could use isc4.gdb.

My thinking here, is that if you had two production databases, and
two test databases, you could use the internal copy in the production
databases, where legitimately users who use one, don't need to know
the other exists. The test databases could use isc4.gdb where
legitimately the developers would have access to both.





Paul Schmidt,
Tricat Technologies
Email: paul@...
Website: www.tricattechnologies.com