<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Accessing file-gdb over network not advisable, why? in Data Management Questions</title>
    <link>https://community.esri.com/t5/data-management-questions/accessing-file-gdb-over-network-not-advisable-why/m-p/619716#M35010</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;So Vince if I read your comment correctly, multi-user file-gdb performance between two 'nix machines over NFS should operate close to optimal, but anything involving Windows will have problems? (including 'nix and Samba/CIFS?)&amp;nbsp; ...which pretty much means anything involving Arcmap is trouble. Can you put a number on how many ArcGIS Desktop clients are involved when Microsoft networking starts becoming problematic?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;The background for my question is that we've been using a file-gdb central store for our department for sometime and are contemplating moving to an RDBMS store, primarily to take advantage of gdb replication to district offices, secondarily for true topology etc. We've also been experiencing decaying performance issues over a number of months and are wondering if multi-user file-gdb is at root. Staying with a file-gdb store is attractive because we don't have any dedicated SysAdmins or DBA's around to build, tune and maintain an RDBMS, but in the end performance could be the deciding factor. (So cross our fingers and hope a spousal "yes dear" install of ArcGIS Server and Postgres is enough.)&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Centrally we have 6 to 10 active daily use ArcGIS Desktop users, 2 to 3 data editors (but this happens rarely, once a week perhaps), 25-50 readers, currently using ArcReader but looking to migrate to web maps (served from a local ArcGIS server).&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;thanks in advance for your thoughts.&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Thu, 26 Jun 2014 19:07:20 GMT</pubDate>
    <dc:creator>mattwilkie</dc:creator>
    <dc:date>2014-06-26T19:07:20Z</dc:date>
    <item>
      <title>Accessing file-gdb over network not advisable, why?</title>
      <link>https://community.esri.com/t5/data-management-questions/accessing-file-gdb-over-network-not-advisable-why/m-p/619713#M35007</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;In another thread the formidable Vince Angelo was seen &lt;/SPAN&gt;&lt;A href="http://forums.arcgis.com/threads/113284-Overwriting-a-File-Geodatabase-while-in-use?p=397369&amp;amp;viewfull=1#post397369"&gt;saying&lt;/A&gt;&lt;SPAN&gt; &lt;/SPAN&gt;&lt;SPAN style="font-style:italic;"&gt;"It's best practice to not access FGBDs over a network link"&lt;/SPAN&gt;&lt;SPAN&gt;. Would someone in the know please expand on that? What makes it not best practice? &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I'm most interested in read-by-many users and write-by-one (or few) scenario but please feel free to go beyond that. Thanks.&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 25 Jun 2014 20:56:17 GMT</pubDate>
      <guid>https://community.esri.com/t5/data-management-questions/accessing-file-gdb-over-network-not-advisable-why/m-p/619713#M35007</guid>
      <dc:creator>mattwilkie</dc:creator>
      <dc:date>2014-06-25T20:56:17Z</dc:date>
    </item>
    <item>
      <title>Re: Accessing file-gdb over network not advisable, why?</title>
      <link>https://community.esri.com/t5/data-management-questions/accessing-file-gdb-over-network-not-advisable-why/m-p/619714#M35008</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;File Geodatabases are frustrating for multiuser/enterprise environments.&amp;nbsp; I believe Vince was replying to that user's specific situation, which included an interest in refreshing data which could be actively in use.&amp;nbsp; If someone is connected to the fgdb when you wish to modify it, you're out of luck unless you're ok with bouncing the server.&amp;nbsp; So in this context, an enterprise SDE geodatabase is preferable, as you can identify locks and take advantage of versioning and replication.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;There may be more to it, but I suspect it is logistics, rather than network limitations, which inform this advice.&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 26 Jun 2014 02:29:31 GMT</pubDate>
      <guid>https://community.esri.com/t5/data-management-questions/accessing-file-gdb-over-network-not-advisable-why/m-p/619714#M35008</guid>
      <dc:creator>Anonymous User</dc:creator>
      <dc:date>2014-06-26T02:29:31Z</dc:date>
    </item>
    <item>
      <title>Re: Accessing file-gdb over network not advisable, why?</title>
      <link>https://community.esri.com/t5/data-management-questions/accessing-file-gdb-over-network-not-advisable-why/m-p/619715#M35009</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;It's not so much "network limitations" as it is "Microsoft networking" which is the&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;major determinate.&amp;nbsp; For some reason never adequately explained, a perfectly&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;reasonable set of read() operations across multiple files, when executed across&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;a network on a Windows operating system, becomes a major performance snarl.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;I don't have the time to do a benchmark right now to give hard numbers, but the&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;same performance difference does &lt;/SPAN&gt;&lt;SPAN style="font-style:italic;"&gt;not&lt;/SPAN&gt;&lt;SPAN&gt; generally exist over NFS between two&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Unix nodes.&amp;nbsp; Read/write operations are also significantly affected, and multi-user&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;read/write, with it's attendant locking issues, just makes it worse. &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;- V&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 26 Jun 2014 10:13:16 GMT</pubDate>
      <guid>https://community.esri.com/t5/data-management-questions/accessing-file-gdb-over-network-not-advisable-why/m-p/619715#M35009</guid>
      <dc:creator>VinceAngelo</dc:creator>
      <dc:date>2014-06-26T10:13:16Z</dc:date>
    </item>
    <item>
      <title>Re: Accessing file-gdb over network not advisable, why?</title>
      <link>https://community.esri.com/t5/data-management-questions/accessing-file-gdb-over-network-not-advisable-why/m-p/619716#M35010</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;So Vince if I read your comment correctly, multi-user file-gdb performance between two 'nix machines over NFS should operate close to optimal, but anything involving Windows will have problems? (including 'nix and Samba/CIFS?)&amp;nbsp; ...which pretty much means anything involving Arcmap is trouble. Can you put a number on how many ArcGIS Desktop clients are involved when Microsoft networking starts becoming problematic?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;The background for my question is that we've been using a file-gdb central store for our department for sometime and are contemplating moving to an RDBMS store, primarily to take advantage of gdb replication to district offices, secondarily for true topology etc. We've also been experiencing decaying performance issues over a number of months and are wondering if multi-user file-gdb is at root. Staying with a file-gdb store is attractive because we don't have any dedicated SysAdmins or DBA's around to build, tune and maintain an RDBMS, but in the end performance could be the deciding factor. (So cross our fingers and hope a spousal "yes dear" install of ArcGIS Server and Postgres is enough.)&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Centrally we have 6 to 10 active daily use ArcGIS Desktop users, 2 to 3 data editors (but this happens rarely, once a week perhaps), 25-50 readers, currently using ArcReader but looking to migrate to web maps (served from a local ArcGIS server).&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;thanks in advance for your thoughts.&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 26 Jun 2014 19:07:20 GMT</pubDate>
      <guid>https://community.esri.com/t5/data-management-questions/accessing-file-gdb-over-network-not-advisable-why/m-p/619716#M35010</guid>
      <dc:creator>mattwilkie</dc:creator>
      <dc:date>2014-06-26T19:07:20Z</dc:date>
    </item>
    <item>
      <title>Re: Accessing file-gdb over network not advisable, why?</title>
      <link>https://community.esri.com/t5/data-management-questions/accessing-file-gdb-over-network-not-advisable-why/m-p/619717#M35011</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;BLOCKQUOTE class="jive-quote"&gt;Can you put a number on how many ArcGIS Desktop clients are involved when Microsoft networking starts becoming problematic?&lt;BR /&gt;&lt;/BLOCKQUOTE&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;One, unfortunately, which is why it's not recommended.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Once you have an AGS seat, you should really evaluate database technologies.&amp;nbsp; Yes, running&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;one is expensive (even free databases need administration), but so is having two dozen people&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;waiting on a file geodatabase.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;- V&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 26 Jun 2014 20:17:45 GMT</pubDate>
      <guid>https://community.esri.com/t5/data-management-questions/accessing-file-gdb-over-network-not-advisable-why/m-p/619717#M35011</guid>
      <dc:creator>VinceAngelo</dc:creator>
      <dc:date>2014-06-26T20:17:45Z</dc:date>
    </item>
  </channel>
</rss>

