Latest Contributions by CraigGillgrass

No the domain is not associated with the field. the field type is long and the domain field type is entier long When i verify the list of coded value domain in the database with the tool 'Domain Sort' the domain appear. In order for the domain to appear in ArcMap, it needs to be associated with the field. Can you try manually associating the domain with the field in ArcCatalog and test if that allows you to see the domain dropdown in ArcMap? ... View more

I've never seen this error with Validate Features, I suggest you contact Technical Support so they can investigate your case and look at the data to try and determine the cause of the error. ... View more

Ted, This information is located on the General tab for the Feature Class dialog under the Geometry section. Adding it to the Feature Dataset is not really possible; since Feature Datasets do not have a geometry storage type themselves and it is possible that feature classes contained within a feature dataset can have different storage types. ... View more

Can you confirm that the domain is associated with correct field by checking the Field tab on the Feature Class or Table property page?  Can you also confirm that the field type and domain's field type match? ... View more

A few questions: - What release of ArcGIS are you using? - Do the Coded Value Domains appear when you look at the domain in ArcCatalog? ... View more

Brittany, this could be due to a number of issues, the best way for us to look at the issue is for you to log a tech support incident.  Ask the Analyst to contact me when you have the incident logged. thanks, ... View more

Jacob, We've been investigating NIM064663 and believe we have a fix for it.  One thing we did find is that the issue referenced in the bug was primarily due to connections to the geodatabase using a Desktop client (like ArcCatalog), over a wide area network, such as the internet.  Is this the situation you are in? ... View more

Please contact Technical Support so they can work with you to identify the root cause of the slower connection times at 10.0.  We have gotten reports of this and need you to work with Technical Support to isolate the issue. ... View more

John, If you're using 10.0, take a look at using Attachments.  They allow you to attach files to features within a feature class. ... View more

You can also query the information from the GDB_Items table.  This help topic contains the steps on how to do this: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/Determining_which_data_is_versioned/006z000000v1000000/ ... View more

Chris, Take a look at the following article: http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#/Creating_geodatabases/0001000004t8000000/ It shows how to create geodatabases stored in SQL Server Express. ... View more

32 is a lot of feature classes to have a in a geometric network, it's probably the most number of classes that I've ever seen.  Here's why I'm raising this as an potential issue; as I mentioned, each time you create a new feature, the geodatabase opens a cursor on each class in the network.  If we can handle 5 cursors in 1 second (as an example); you would be looking at over 6 seconds to determine whether there are any features at that location.  This is a cost you are paying every time you create a new feature.  So, I would strongly suggest that you try and re-assess the number of feature classes in your network.  If you are adamant that you cannot either decrease the number of feature classes in the network or drop the network in order to load the features; then consider using a Map Cache.  If you're loading data into discrete areas of you network, with a reasonable number of existing features (reasonable being a couple thousand) you could try to build a Map Cache over the area you're loading the features into.  This could speed up a performance a bit, but you will need to prototype this. ... View more

While there is no limitation to the number of feature classes you can have in a geometric network, every feature class you have in the network comes with a cost. Each time a feature is created, the geometric network has to search through each class and determine if there are any coincident features.  So, the more feature classes you have in the network, the more time it takes to search for any coincident features.  The object loader is essentially a batch loader that automates the loading of features; but it still has to create them one at a time. I'd suggest that you look at ways of decreasing the number of feature classes in your network by combining several feature classes into 1 and using subtypes.  You can also look at eliminating any feature classes that aren't being used at this time, if you've added empty feature classes to the network thinking you'll use them at some point in the future, remove them and only add them when needed. you best option is probably to delete the geometric network, get all your data loaded and then recreate it.  It will no doubt be much faster. You never responded with how many features you are loading into the network. Can you respond with that? ... View more

Without more specifics on the relationship classes you want to create, I can't really comment on the data model structure.  Your examples, while helpful, don't really demonstrate how you'd like to use the relationship classes. ... View more

The object loader in ArcMap is the recommended method of loading data into a geometric network after it has been created.  Can you clarify how many features you loading and how many feature classes are in the geometric network? ... View more