topic Re: Table DIRTYAREAS in Network Dataset on SQL SERVER in Geodatabase Questions

Table DIRTYAREAS in Network Dataset on SQL SERVER

AlessandroValra — Wed, 27 Jul 2016 08:41:36 GMT

Hello, I'm working on a server with ArcGIS Desktop 10.3.1 and 10.3.1 Server with Network Analyst Extension (one for testing and one for production): my problem is in the copy from test server to production server of the Network Dataset , and connected Feature Class (sde on SQL Server): the copy requires several minutes (too many for the content, about 1,000 arches) and often the operation remains in the state 'Not Responding'.

it seems that are also copied many Dirty Areas (see table ND_ <ITEMID> _DIRTYAREAS in http://desktop.arcgis.com/en/arcmap/10.3/manage-data/gdbs-in-sql-server/network-dataset-storage-sqlserver.htm).

About 4000 records, that really does not seem to be useful, because on dataset is already done the build. Also as a result of a Compress the DB, the records in the table ND_ <ITEMID> _DIRTYAREAS remain.

Is there a way to ease these tables? I can manually delete dirty Areas that have the field 'isretired' = 1?

Thanks in advance..

Re: Table DIRTYAREAS in Network Dataset on SQL SERVER

George_Thompson — Wed, 27 Jul 2016 13:07:44 GMT

Hi Alessandro,

I would not modify (delete/truncate/remove) and of the records from the _DIRTYAREAS table. That is a system table for the network dataset and could cause corruption. It looks like that table is tracking all edits to ND data.

Is there an issue related to that table having data, besides the copy time? Is there a performance issue with the ND?

As for the compress, it only would possibly impact the delta and base tables for versioned data.

Geodatabase compression—Help | ArcGIS for Desktop

-George

Re: Table DIRTYAREAS in Network Dataset on SQL SERVER

AlessandroValra — Wed, 23 Nov 2016 14:21:53 GMT

Thanks George for the response and sorry for delayed feedback.

This printscreen show that during copy there are 7565 record...

No performance issue with the ND... is for me strange that unnecessary records was copied... and I expected that the compress did cleaning.

It could be that after a few years this table reaches considerable size, extending more and more copying time.

I'm considering to use append command in place of copy. Maybe it's better...