<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.esri.com/Dev/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Why should I be making direct connections to an ArcSDE geodatabase?</title><link>http://blogs.esri.com/Dev/blogs/geodatabase/archive/2008/09/05/Why-should-I-be-making-direct-connections-to-an-ArcSDE-geodatabase_3F00_.aspx</link><description>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</description><dc:language>en</dc:language><generator>CommunityServer 2.1 SP2 (Debug Build: 61120.2)</generator><item><title>re: Why should I be making direct connections to an ArcSDE geodatabase?</title><link>http://blogs.esri.com/Dev/blogs/geodatabase/archive/2008/09/05/Why-should-I-be-making-direct-connections-to-an-ArcSDE-geodatabase_3F00_.aspx#2614</link><pubDate>Mon, 08 Sep 2008 21:25:08 GMT</pubDate><guid isPermaLink="false">b60b3f0a-e2bd-4be5-8a18-822c697649ab:2614</guid><dc:creator>ssalas</dc:creator><description>&lt;p&gt;From your post: &amp;nbsp;&amp;quot;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.&amp;quot;&lt;/p&gt;
&lt;p&gt;If that is now the case then I need to start looking at this... &amp;nbsp;&lt;/p&gt;
&lt;p&gt;My ArcSDE training book from way-too-many-years-ago said: &amp;nbsp;&amp;quot;Direct connections require more network resources than application server connections for two reasons. &amp;nbsp;One reason is that the ArcSDE direct connect driver running on the client sends SQL over the network to its Oracle server, as opposed to a gsrvr process doing the same in memory on the server computer. &amp;nbsp;Also, secondary spatial filtering is performed on the client, rather than by a gsrvr process on the server computer&amp;quot; (ArcSDE Admin. for Oracle, ver. 3.1 April 2003).&lt;/p&gt;
&lt;p&gt;We were still going to look at Direct Connect for the OS authentication possibilities, but if the network load penalty is no longer valid anymore, that should make it more of a priority for our organization. - Thanks!&lt;/p&gt;
</description></item><item><title>re: Why should I be making direct connections to an ArcSDE geodatabase?</title><link>http://blogs.esri.com/Dev/blogs/geodatabase/archive/2008/09/05/Why-should-I-be-making-direct-connections-to-an-ArcSDE-geodatabase_3F00_.aspx#2621</link><pubDate>Mon, 08 Sep 2008 23:54:25 GMT</pubDate><guid isPermaLink="false">b60b3f0a-e2bd-4be5-8a18-822c697649ab:2621</guid><dc:creator>tb</dc:creator><description>&lt;p&gt;In response to ssalas posting:&lt;/p&gt;
&lt;p&gt;The ArcGIS/ArcSDE 9.0 for Oracle release focused on several performance and scalability enhancements. We focused on how to decrease CPU usage in the Oracle instance and increase the scalability of the system. We accomplished this by implementing a cursor cache model which allowed us to hold spatial cursors, internal metadata cursors, editing cursors and anonymous pl/sql blocks. By doing this, when we re-execute a held cursor the only information which had to be sent to the Oracle instance were the bind values and the call to execute the statement handle.&lt;/p&gt;
&lt;p&gt;This significantly reduced the amount of network traffic for direct connect because we were no longer having to prepare each cursor (statement handle) and send it over the network to the Oracle instance.&lt;/p&gt;
&lt;p&gt;The amount of data being fetched and sent over the network, with either direct connect or application server, is almost identical - meaning if the data is sent via the DBMS protocals or the SDE compressed shapes.&lt;/p&gt;
&lt;p&gt;Therefore, by running direct connect the communication between the client application and SDE process is all local, and this is the cost saving on the network and why direct connect uses less network then when using an application server connection.&lt;/p&gt;
&lt;p&gt;Good luck.&lt;/p&gt;
</description></item><item><title>re: Why should I be making direct connections to an ArcSDE geodatabase?</title><link>http://blogs.esri.com/Dev/blogs/geodatabase/archive/2008/09/05/Why-should-I-be-making-direct-connections-to-an-ArcSDE-geodatabase_3F00_.aspx#6669</link><pubDate>Mon, 29 Jun 2009 21:46:13 GMT</pubDate><guid isPermaLink="false">b60b3f0a-e2bd-4be5-8a18-822c697649ab:6669</guid><dc:creator>bleung66</dc:creator><description>&lt;p&gt;I've noticed that direct connects lock feature datasets as well as feature data classes. In some cases, these locks remain even though a user is not actually connected to the database (I think these locks are left over from ArcMap or ArcCatalog crashing). Application connects seem much easier to manage the database if you are required to load new data or modify schema. Has anyone else run into this problem?&lt;/p&gt;
</description></item></channel></rss>