|
POST
|
Do you have another administrative connection to ArcGIS Server open from another machine? I don't think that should matter but try stopping and starting the ArcGIS for Server service in the Windows Services console.
... View more
04-28-2014
02:56 AM
|
0
|
0
|
1144
|
|
POST
|
Folders are shared for desktop access, not necessarily for server access; especially in the circumstance I think you described. Sharing folders for the purposes of ArcGIS for Server would really only be needed if you needed to publish services that reference data residing within the shared folder. Before publishing, you would need to register the folder with the data store. In any case, it sounds like you might need to make a folder connection within ArcGIS for Desktop. You can connect to local folders or UNC paths using the method described here. Connecting to an ArcGIS Server is not the way to access a shared folder. Let me know if this resolves your issue.
... View more
04-27-2014
04:58 PM
|
0
|
0
|
1969
|
|
POST
|
Ed, I'm so glad it worked for you! Thanks for the follow-up and for letting me know. I'm up for a beer anytime... no need to buy. Maybe sometime if you're at the Esri UC we can get a chance to meet. Have a great weekend!
... View more
04-23-2014
05:30 PM
|
0
|
0
|
1950
|
|
POST
|
To take this a step further, the Allowed Admin Access IPs section of the AGS Administrator API (found under Security > Config) allows you to control which IP addresses for client machines have access to the Administrative API. This can be used as an additional security measure to prevent any un-authorized access to the server. Just input a comma-separated list of IP addresses for client machines of known users who you wish to grant access (assuming your network assigned static IPs).
... View more
04-23-2014
05:27 PM
|
2
|
0
|
4078
|
|
POST
|
Please provide the version of ArcGIS Server you are using along with any relevant API (e.g., Flex, Javascript, Silverlight).
... View more
04-23-2014
05:16 PM
|
0
|
0
|
1721
|
|
POST
|
Maybe. Oracle is supposed to automatically tune the undo retention size when set to AUTO. If you're open to modifying the value and this isn't a production database, try something like this in SQLplus and then attempt to create your geometric network again after making a new connection: ALTER SYSTEM SET UNDO_RETENTION = 150000; If it doesn't work, then change it back to the default setting of 900: ALTER SYSTEM SET UNDO_RETENTION = 900;
... View more
04-23-2014
05:06 PM
|
0
|
0
|
1950
|
|
POST
|
What are the results of this query when run against Oracle as SYS? SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
ROUND((d.undo_size / (to_number(f.value) *
g.undo_block_per_sec)))"OPTIMAL UNDO RETENTION [Sec]"
FROM (
SELECT SUM(a.bytes) undo_size
FROM v$datafile a,
v$tablespace b,
dba_tablespaces c
WHERE c.contents = 'UNDO'
AND c.status = 'ONLINE'
AND b.name = c.tablespace_name
AND a.ts# = b.ts#
) d,
v$parameter e,
v$parameter f,
(
SELECT MAX(undoblks/((end_time-begin_time)*3600*24))undo_block_per_sec
FROM v$undostat
) g
WHERE e.name = 'undo_retention'
AND f.name = 'db_block_size';
... View more
04-23-2014
04:52 PM
|
0
|
0
|
1950
|
|
POST
|
Which version of Oracle? I am wondering if your UNDO tablespace is being exhausted when creating the geometric network(s) in Oracle due to an extremely long transaction; especially since you mentioned that 4 T_* tables briefly exist. How long does it run against Oracle before it fails? You also said earlier that it worked in a file geodatabase. Log into your Oracle database via SQLplus and check your undo parameters: SHOW PARAMETER undo You should see something similar to this: undo_management string AUTO undo_retention integer 3600 undo_tablespace string UNDOTBS1 I'm specifically interested in seeing your undo retention parameter value. It might be that the undo retention value is too large, or the UNDO tablespace is to small. If it is too large, then Oracle will keep buffering data until the tablespace fills up. I've found this article to be helpful at times.
... View more
04-23-2014
04:43 PM
|
0
|
0
|
3759
|
|
POST
|
Direct connections produce a client log file named sdedc_<RDBMS>.log (substitute something like 'oracle' or 'sqlserver' in place of <RDBMS>). The file is typically generated and stored under the profile directory for the logged-in user on machines using a Microsoft Windows operating system. For example: For Windows 2008 R2, usually C:\users\<userID>\AppData\Local\Temp Since you didn't provide your OS, I'm going to assume Windows for the time being. I don't believe you can change the type of logging that gets recorded in this file; in other words, I don't think it is configurable to something more verbose than it already is. What specifically are you trying to capture? There are other methods of capturing events, calls, etc. besides the direct connect log file. Sometimes a session trace using RDBMS tools might be sufficient (e.g., Oracle trace or SQL profiler trace), but other times you might need something more Esri-centric. Have you considered using an SDETRACE or an SDEINTERCEPT? I'm not sure what exactly you're trying to do, but these are all methods of capturing events between different parts of the system which include some that interact directly with the client.
... View more
04-22-2014
12:20 PM
|
0
|
2
|
2840
|
|
POST
|
How are those features being added and deleted? Is this being done inside an edit session or outside an edit session? If you're deleting and adding tens of thousands of features on a daily basis, you might want to consider re-building the spatial indexes on those feature classes accordingly each time the number of records changes drastically. The need for doing this is rare, but it can happen depending on how the features are being added/deleted. I also believe this is more likely to happen when the changes are made in an edit session. As an example, a spatial index calculated for 50,000 lines might look much different than a spatial index for 140,000 lines in terms of grid size. Check out these articles to understand a bit more about spatial indexes: http://resources.arcgis.com/en/help/main/10.1/index.html#//003n0000001r000000 http://resources.arcgis.com/en/help/main/10.1/index.html#//003n0000001s000000 So, your workflow might need to change to something like this at a high level: Start edit session. Delete 50,000 lines. Recalculate the spatial index. After several hours, add 80,000 lines. Recalculate the spatial index.
... View more
04-21-2014
08:12 AM
|
0
|
0
|
2521
|
|
POST
|
Please mark the correct answer with the green check to the right of the appropriate post. Thank you!
... View more
04-21-2014
07:46 AM
|
0
|
0
|
3215
|
|
POST
|
Fiddler is a free web debugging proxy which logs all HTTP(s) traffic between your computer and some host (e.g., your GIS server). You can use it to debug traffic in order to see the content of requests and responses so you can identify where the failure might be. Download the appropriate version of the Fiddler software here. Open Fiddler, then re-try your add feature operation, then save the results to a SAZ file in Fiddler and post it here.
... View more
04-21-2014
06:15 AM
|
0
|
0
|
2754
|
|
POST
|
Which operations (e.g., Create, Delete, Update, Query) have you specified as 'allowed' for Feature Access within the service properties? Also, you should check the requests and responses using Fiddler. What are the results from running Fiddler during the attempt to add the new feature?
... View more
04-20-2014
06:40 PM
|
0
|
0
|
2754
|
|
POST
|
It sounds to me like something didn't get deleted fully/correctly. It is possible that you can manually hack the database to resolve the issue, but it's dangerous and certainly not supported by Esri. Since this isn't for the faint of heart, proceed with caution if this really ends up being your problem to begin with. I'm not sure which spatial data type you're using, but you may have some lingering delta tables (A and D) and potentially the features and spatial tables (F and S tables) as well. Additionally, you likely have some lingering references to the partially-deleted feature class within your ArcSDE system tables. Make a backup of your database first, then try the steps below: BTW, I apologize but these queries are written for Oracle but they can be slightly modified to fit your SQL Server environment depending on your schema (DBO vs SDE). First, find out the names of the A, D, S, and F tables for your deleted versioned feature class. To do this, run the query below and scroll down in the result set in order to your feature class to identify the right table names: select
substr(l.TABLE_NAME,1,30) table_name,
substr('F'||layer_id,1,10) feature_table,
substr('S'||layer_id,1,10) spatial_table,
substr('A'||registration_id,1,10) adds_table,
substr('D'||registration_id,1,10) deletes_table,
substr(l.OWNER,1,12) owner
from sde.layers l, sde.table_registry r
where l.owner NOT IN ('SDE')
and l.table_name = r.table_name (+)
and l.owner = r.owner (+)
order by owner, table_name Second, delete the A and D tables (as well as the S and F tables if you were not using a spatial data type like ST_Geometry) for the feature class you intended to delete (if they still exist). In other words, use SQL Server Management Studio to delete the tables from the database entirely that were provided from the query above. Third, (this is where it can get tricky) you will need to make sure there isn't a reference to it in the SDE Layers and Table Registry tables within the ArcSDE system tables. Try something like this (substitute your feature class name for 'deleted_ feature_class'): DELETE FROM DBO.GDB_ITEMS WHERE NAME = 'deleted_feature_class';
DELETE FROM DBO.GDB_TABLES_LAST_MODIFIED WHERE TABLE_NAME = 'deleted_feature_class';
DELETE FROM DBO.SDE_column_registry WHERE TABLE_NAME = 'deleted_feature_class';
DELETE FROM DBO.SDE_layers WHERE TABLE_NAME = 'deleted_feature_class';
DELETE FROM DBO.SDE_table_registry WHERE TABLE_NAME = 'deleted_feature_class';
DELETE FROM DBO.SDE_tables_modified WHERE TABLE_NAME = 'deleted_feature_class';
You can really hose up your geodatabase if you're not careful (hence, taking the backup from earlier), so be careful with the SQL above. Fourth, try to re-register your dataset as versioned. As an alternative to all of the steps above, you could try unversioning the entire dataset and then try to version it again. I doubt that will help but it might be worth a shot. Good luck. Post back to let us know the results.
... View more
04-18-2014
06:14 PM
|
0
|
0
|
754
|
|
POST
|
Is your new field simply not appearing in the list of fields from which to choose? What is the data type of the new field you added and calculated; text or numeric? Raster grids in ArcGIS need to use integer or floating-point values for the attribute in the raster attribute table. Thus, you cannot use a text field in a vector attribute table for the cell assignment in converting vector data to raster data. If your new field is TEXT, try changing it to numeric (e.g., DOUBLE, FLOAT, LONG) when adding it and prior to calculating it.
... View more
04-16-2014
05:34 PM
|
0
|
0
|
639
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | 04-05-2014 04:11 PM | |
| 1 | 02-19-2014 11:03 AM | |
| 1 | 04-07-2014 12:32 PM | |
| 1 | 04-03-2019 01:46 PM | |
| 1 | 03-31-2021 04:44 PM |
| Online Status |
Offline
|
| Date Last Visited |
07-13-2025
07:13 PM
|