Why should I be making direct connections to an ArcSDE geodatabase?

As I was at the UC this year talking with geodatabase users, it became clear to me that there are still a large number of geodatabase users out there who are connecting to an ArcSDE geodatabase through an application server connection. While both connection types are valid, in many cases it makes much more sense to use direct connect over application server connections. I feel many users might not know the benefits of using a direct connection to a geodatabase so this blog post will attempt clear this up, but first, a little background information…

There are two different ways that ArcGIS can connect to an ArcSDE geodatabase: through an application server connection or through a direct connection. The real difference between the two connection types is where (what machine) the work is being done.

The application server connection type uses a gsrvr process which executes SQL and performs spatial processing, where as with direct connect, this gsrvr process is embedded in the client application that is making the connection.

What this means is that if you make a direct connection to a geodatabase through ArcMap or ArcCatalog, the machine making the connection will connect and do all the spatial processing associated with working with the data in the geodatabase. With an application server connection (sometimes referred to as an ArcSDE service connection), all the spatial processing will be done on the machine that is running the ArcSDE service.

This is probably best highlighted through a graphic.

As you can see, the type of connection really just dictates where the spatial processing is being done (the gsrvr process in the graphic); in the direct connect case the gsrvr is process is executing on the connecting machine in the application server case the gsrvr is running on the machine in the server tier.

I know what you are saying “Okay, that’s great but which one do I use?”. In today’s world, desktop computers have become very powerful and I can see no reason why this trend won’t continue as hardware becomes less expensive. With this in mind, it makes good sense to distribute the gsrvr processes over all the connecting machines rather than force every connection to use the resources of one machine running an ArcSDE service. As a side note, the machine running the ArcSDE service is typically the DBMS server as well (the machine running the database) and by using direct connect you avoid overloading this machine with many gsrvr processes. Another advantage of direct connect is that it can help reduce network traffic because only the SQL statements and the fetched data is passed over the network.

So, what’s the catch with using direct connect?

Since we added the reverse compatibility of the direct connect drivers at 9.3 there really isn’t one. Well, to be truthful there is one consideration; you do have to make sure that the appropriate database client software is installed on the machine you are making the connection from. This usually isn’t a big deal, the database client installation is quick and painless and requires little configuration once installed. Even better, if you are connecting to SQL Server, that database client is already part of Windows so no installation is necessary. Similarly, for PostgreSQL, no additional database client installation is required.

How do I do it?

The best resource is the direct connect client setup overview topic in our online help.