Why would I install ArcSDE with 10.1?

14693
71
Jump to solution
05-10-2012 11:01 AM
AlanToms
Occasional Contributor
Hello all,
Why would I install ArcSDE with 10.1?  It seems I can us ArcCatalog to create an enterprise geodatabase without SDE then have all my users use direct connections.  What am I missing?

Thank you
Alan
1 Solution

Accepted Solutions
RussellBrennan
Esri Contributor
Alan,

To further add on to what Jake said...

Prior to 10.1 (10.0, 9.x, 8.x) if you wanted to use a Geodatabase with all of the cool Geodatabase functionality (versioning, archiving, topology, relationship classes, terrains, geometric networks, etc) on a DBMS (Oracle, SQL Server, Postgresql, Informix, DB2) you had to perform a few steps.

First, you needed to install ArcSDE onto your machine, usually this was your DBMS server. This install included the files needed to run ArcSDE command line utilities, the application server, as well as the ArcSDE post installer.

After installing this onto your machine you would need to run the ArcSDE post installer. The main purpose of this post install was to install the Geodatabase into your enterprise database. This includes all the stored procedures, functions, privileges, and schema needed to provide the functionality I mentioned earlier. The post install could also be used to set up your application server.

The application server can be used to connect from a client machine to the DBMS/Geodatabase. It is used more or less to manage the connection requests coming in from clients and provide a way for the clients to 'talk' to the DBMS. For a while this was the only way to connect to a Geodatabase. At some point (I think 9.0) we added the ability to make direct connections (2-tier: client-DBMS) to the DBMS. This made the use of the application server (3-tier: client-app server-dbms) optional. For some people this meant they stopped setting up the application server and started using direct connections. Others continued using the application server.

The ArcSDE command line utilities are a method for the Geodatabase administrator to manage data, users, the application server service.

Fast forward to 10.1 - We have tried to allow you to manage your Geodatabase completely within ArcGIS applications (ArcCatalog, ArcMap, ArcGIS Server, etc). This is done through the use of dialogues in ArcMap/Catalog and the use of geoprocessing. The first thing we did was to break out the installation of the geodatabase schema tasks into geoprocessing tools. If you want to create an enterprise geodatabase there are now two options. Option 1, you can use the 'Create Enterprise Geodatabase' geoprocessing tool. This tool will create a new empty geodatabase in an existing instance. The second option is to use the 'Enable Enterprise Geodatabase' tool will allow you to install the Geodatabase schema in an already existing instance. The new functionality that Jake mentioned that allows you to now connect to a enterprise database (not a geodatabase) is what allow ArcGIS to then enable geodatabase behavior in your enterprise geodatabase. This second option would be used where you have already set up a database, have user permissions assigned and maybe have loaded some data (essentially converting your database to a geodatabase). The first option would be used if you are starting from nothing.

Esri recommends using direct connections for making connections to your geodatabase, it is not mandatory that you install the application server.

Much of the commonly used functionality found in the ArcSDE command line utilities is now available either through ArcGIS applications mentioned earlier or through geoprocessing (disconnecting users, identifying locks, loading data, investigating data, etc). For most users the install of these utilities should not be necessary.

If you determine that you really need the application server or the command line utilities they are available as a separate install.

So, this has been a pretty long winded answer to a pretty straightforward question. Answer is, it's not mandatory to install the application server or command line utilities. If you want to take advantage of Geodatabase behavior you do need to run one of the geoprocessing tools to install the Geodatabase.

View solution in original post

71 Replies
JakeSkinner
Esri Esteemed Contributor
Hi Alan,

With ArcGIS 10.1 you can connect to an enterprise database that does not have an SDE geodatabase repository and create feature classes with a native spatial type.  For example, you could connect to a SQL Server database and import/create feature classes with the GEOMETRY or GEOGRAPHY spatial type.  However, you can only view this feature class.  You cannot perform any edits, or have the feature class participate in any geodatabase functionality (such as replication, topology, geometric networks, relationship classes, network datasets, etc).  Essentially, you are getting a 'view' only feature class w/o SDE.
Reply
0 Kudos
RussellBrennan
Esri Contributor
Alan,

To further add on to what Jake said...

Prior to 10.1 (10.0, 9.x, 8.x) if you wanted to use a Geodatabase with all of the cool Geodatabase functionality (versioning, archiving, topology, relationship classes, terrains, geometric networks, etc) on a DBMS (Oracle, SQL Server, Postgresql, Informix, DB2) you had to perform a few steps.

First, you needed to install ArcSDE onto your machine, usually this was your DBMS server. This install included the files needed to run ArcSDE command line utilities, the application server, as well as the ArcSDE post installer.

After installing this onto your machine you would need to run the ArcSDE post installer. The main purpose of this post install was to install the Geodatabase into your enterprise database. This includes all the stored procedures, functions, privileges, and schema needed to provide the functionality I mentioned earlier. The post install could also be used to set up your application server.

The application server can be used to connect from a client machine to the DBMS/Geodatabase. It is used more or less to manage the connection requests coming in from clients and provide a way for the clients to 'talk' to the DBMS. For a while this was the only way to connect to a Geodatabase. At some point (I think 9.0) we added the ability to make direct connections (2-tier: client-DBMS) to the DBMS. This made the use of the application server (3-tier: client-app server-dbms) optional. For some people this meant they stopped setting up the application server and started using direct connections. Others continued using the application server.

The ArcSDE command line utilities are a method for the Geodatabase administrator to manage data, users, the application server service.

Fast forward to 10.1 - We have tried to allow you to manage your Geodatabase completely within ArcGIS applications (ArcCatalog, ArcMap, ArcGIS Server, etc). This is done through the use of dialogues in ArcMap/Catalog and the use of geoprocessing. The first thing we did was to break out the installation of the geodatabase schema tasks into geoprocessing tools. If you want to create an enterprise geodatabase there are now two options. Option 1, you can use the 'Create Enterprise Geodatabase' geoprocessing tool. This tool will create a new empty geodatabase in an existing instance. The second option is to use the 'Enable Enterprise Geodatabase' tool will allow you to install the Geodatabase schema in an already existing instance. The new functionality that Jake mentioned that allows you to now connect to a enterprise database (not a geodatabase) is what allow ArcGIS to then enable geodatabase behavior in your enterprise geodatabase. This second option would be used where you have already set up a database, have user permissions assigned and maybe have loaded some data (essentially converting your database to a geodatabase). The first option would be used if you are starting from nothing.

Esri recommends using direct connections for making connections to your geodatabase, it is not mandatory that you install the application server.

Much of the commonly used functionality found in the ArcSDE command line utilities is now available either through ArcGIS applications mentioned earlier or through geoprocessing (disconnecting users, identifying locks, loading data, investigating data, etc). For most users the install of these utilities should not be necessary.

If you determine that you really need the application server or the command line utilities they are available as a separate install.

So, this has been a pretty long winded answer to a pretty straightforward question. Answer is, it's not mandatory to install the application server or command line utilities. If you want to take advantage of Geodatabase behavior you do need to run one of the geoprocessing tools to install the Geodatabase.

View solution in original post

RickWarner
New Contributor III

Would ArcSDE be appropriate for a single user who works on a standalone workstation?

Do you know if using ArcSDE If I would be able to connect Crystal Reports 2008 to the geodatabases directly, rather than I know have to export to a personal geodatabase?

Thank you

Reply
0 Kudos
AlanToms
Occasional Contributor
Thank you very much for the education.

Alan
Reply
0 Kudos
ShannonShields
Esri Contributor
Hi Alan,

at 10.1 there is no need to install the ArcSDE software unless you need to run an ArcSDE service. If all of your users are making Direct Connections to the geodatabase then the ArcSDE installation is not necessary. As well, most of the functionality offered by ArcSDE commands is now available in ArcGIS Desktop & through GP tools.

-Shannon
LucaSimone
New Contributor III
the answer from russellb is really clear, but I have another little question:

what about editing?

I have some services that I can edit on the web with ArcGIS Server 10.1, should I still use the SDE connection or it is ok to use a direct Connection?
Is the new ArcGIS Server able to 'replace' or acts as the SDE layer?
Reply
0 Kudos
VinceAngelo
Esri Esteemed Contributor
Direct Connect *is* an ArcSDE connection.  This thread is about application server install,
but the ArcSDE functionality still exists -- It's ArcSDE that provides the basis for versioned
geodatabases.  With Direct Connect, it's just a multi-threaded solution in the ArcGIS client
instead of a multi-processing solution on the database server.

- V
Reply
0 Kudos
AlaaKutbi
New Contributor II
You cannot perform any edits, or have the feature class participate in any geodatabase functionality (such as replication, topology, geometric networks, relationship classes, network datasets, etc). Essentially, you are getting a 'view' only feature class w/o SDE.


Is the qouted text true if I don't install ArcSDE 10.1?
Reply
0 Kudos
MarcoBoeringa
MVP Regular Contributor
Is the qouted text true if I don't install ArcSDE 10.1?


No, it's true, like Russell Brennan wrote, if you don't Create or Enable Enterprise Geodatabase functionality on your database using the new geoprocessing tools in ArcGIS 10.1.

It has nothing to do with whether or not ArcSDE is installed on your database server. As Vince says, even if you don't use or install it on your database server, ArcSDE is still part of your client ArcGIS application, there are by default DLLs installed on your own computer with ArcGIS that handle the geodatabase SQL logic ---> That is essentially what ArcSDE is!

E.g., have a look at your "C:\Program Files (x86)\ArcGIS\Desktop10.X\Bin" folder on your local computer. You will see DLLs like "sde.dll" and "sdesqlsrvr100.dll" etc.

As soon as you attempt to connect to an ESRI Enterprise Geodatabase, these DLLs will be in use by your client ArcGIS application. There is no way around this when connecting to an ESRI geodatabase - at least for full functionality including editing - ArcSDE is just the component ESRI devised to handle the connection to the database and SQL stuff needed to allow advanced geodatabase functionality like versioning.

There is nothing special about ArcSDE or these DLLs in this respect, other vendors like Bentley or Autodesk have similar software components in their software to handle connections and SQL stuff related to geospatial databases, they just call it differently.
Reply
0 Kudos