Some basic SDE questions

[DonFreeman]

Using MS terminology, I have an "instance" of sqlexpress named SQLExpress64.
The instance contains a "database" named MySDE.
MySDE includes a geodatabase plus other tables created with Management Studio.
The featureclasses in the geodatabase have been joined with the non-esri tables which are also in the MySDE database and have been published as a web service.
The features in the geodatabase have been successfully edited via a web application.
A look at the services on the server box shows SDE is NOT running.
Attempts to start the SDE service result in errors that suggest a look at the installation instructions.
Now the questions:

1. Does this make sense? If all this is possible with SDE NOT running, what do I need SDE for? 

2. Assuming the above problem is fixed, can a geodatabase be added to a preexistant "database"?

3. Can there be more than one SDE enabled "database" in the SQLExpress64 instance with different sets of users and permissions? If yes, how would the second one be created?

4. In My SDE, I want to have various levels of users. Administrators who have all rights, GISStaff who can edit feature topology and add new feature classes but not edit the non-esri tables, WebUsers who can edit the non-esri tables but not the feature topology, and GeneralUsers who can read but not write data in specified featureclasses and the non-esri tables. All users would have Read/View access. How would I set this up? Some of this will be simplified if the answer to Q3 is yes.

Thanks for any insights into these issues.

[VinceAngelo]

I think your problem is your working definition of "SDE," so some background may help...

When the technology was aquired, "SDBE" was at release 1.3, and had a user base of
roughly twenty sites.  ESRI (as they were then known) put a logo on a box, and "SDE"
version 1.4 was released (Database, not DataBase).  Development immediately set out
to port the code to Oracle (2.0 & 2.1) and to Sybase, DB2 and Informix (2.1.1).  At the
same time the core of the code was taken apart, merged with a development effort known
as the "Projection Engine" and new SDE 3.0 was released. Integration with Arc/Info was s
till limited, but ArcView 3.0 had an SDE accessible API in Avenue, and ArcIMS was able to
connect as well (though not through the nominal AXL editor GUI).  The SDE was integrated
more completely with the new ArcGIS and became ArcSDE 8.0.  Sybase was out and SQL-
Server was in, with support for the single database model (also available in DB2 & Informix).
Direct Connect libraries were added at 9.0 and the GDB tables re-architected at 10.0.

So, to answer your questions:
1) ArcSDE is a network protocol *and* an application server *and* a DLL library. Even
if you have not configured a service, the Direct Connect DLL thread is fully capable of
accessing an ArcSDE-configured database.  ArcSDE technology stopped shipping as a
standalone product at 9.2, but it still remains the method by which versioned geodatabases
are edited by ArcGIS.

2) There are different technology implementations wearing the name "ArcSDE".  Personal
and Workgroup ArcSDE *never* run an application server -- they are usually configured
from scratch in an ArcCatalog session.  Enterprise ArcSDE can use Enterprise, Standard,
and Express releases of SQL-Server, though the Express version is relatively debilitated
by RAM, CPU and dis limitations.  It's far more likely that Enterprise would be joining an
existing instance (and in fact this is recommended over partitioning the geometry from
the rest of the otherwise spatial data).

3) Yes, you may have more than one instance in Express databases, but Express licensing
still limits the storage permitted *across* the databases in an instance ("total" not "each")
I do not recommend splitting data which must be used together across databases. SQL-Server
is very inefficient in mapping users across databases, and rarely needs to be pushed in this
fashion.  Conversely, creating DEV, TEST and PRODUCTION databases for use in isolation
is best practice.

4) Esri tries not to dictate how to configure your database. There are limitations in the games
that can be played in mapping logins to users to schemas, but these are due to limits in
identifying geometry columns in queries without them (see a recent post about when you.
must match user to schema).  It is generally best practice to use roles to grant privileges
to users, and Esri recommends this practice as well.

Personally, I'd find 4Gb or 10Gb of storage and only a fraction of the CPUs and RAM on my
system far too limiting, but I enjoy loading millions of rows of complex data just for kicks.

- V