Latest Contributions by AbhishekSingh

Hi Joe, I am sure that you are aware that the number of users that are connected to the GeoDatabase can be viewed in SDE.SDE_Process_Information table. At times, when the users are disconnected abruptly it can lead to orphaned entries in this table. You can check this by looking at the time since when the connection has been made, if it is dated old it might be an orphaned entry, if it is recent you can get the Node (machine) name from where the connection has been made. This table will also allow you to check if the connection has been made by a user or if it is coming from a published service. Once you know the source of the connection, you may further act for disconnecting users by all means . Some other related tables that you may have to look at is SDE_TABLE_LOCKS and SDE_STATE_LOCKS. Well, the above mentioned method would be the wise way to go about it. Another way (not so wise) would be to alter the parameter CONNECTIONS of the SERVER_CONFIG table. You can do this by using command line - sdeconfig -o alter -v CONNECTIONS =1 -i <connection string or SDE service port number> -s <server_name> -D <Database Name> -u <admin_user> -p <password> The above mentioned command will only allow 1 user to connect with the database, the 2nd connection made to the GeoDatabase would encounter an error - "Unable to connect to database. Maximum number of connection exceeded to instance." Once you have completed with your task, don't forget to change parameter CONNECTIONS back to its original value. -Abhishek ... View more

I totally agree with you, the newer versions must have the older issues/bugs addressed prior to its release. I just thought of mentioning it since the bug was mentioned and the status of the bug still does not show any version on which it is fixed. Changing the storage type from Geography/Geometry to SDE BINARY is lengthy (for data size you mentioned, using the tool Migrate Storage) but if in case you wish to switch back later back from SDE BINARY to Geography/Geometry the tool does not support that. ... View more

Hi Roy, The issue that you have notified about has been reported to ESRI as bug - NIM089563: The PUBLIC role is automatically granted INSERT/UPDATE/DELETE on geodatabase (GDB) tables. I am not sure if it has been fixed. - Abhishek ... View more

Hi Aaron, I see that you have mentioned about the bug - NIM082657.. I just wanted to make sure that you are aware about a related patch for this - ArcGIS 10.1 SP1 for SQL SERVER 2012 Support Patch ArcGIS 10.1 SP1 for (Desktop, Engine, Server) SQL Server 2012 Support Patch | Samples and Utilities Abhishek ... View more

Hi Mark, - It is fine to use the database level tools on sde.default, or in the other words on the business/base table. This can be done by registering the data as versioned (with move edits to base option). Advantage of doing this is that all the edits that you make will go into the delta (adds and deletes) tables as well as the base table, this way you will be able to access all the recent edits without being dependent on the compress process. The disadvantage is that you will not be able to use this data with some functionalities like Replication, Archiving etc.. Refer the following web-link for more information on this -  A quick tour of registering and unregistering data as versioned ArcGIS Help 10.1 - Multi-versioned views are accessible from the database level, therefore you can access them for sure, however there will be some dependency on what database level tools you want to run on them. Mostly, there will be no issues with it since the data created in ArcCatalog is anyway a part of the database. - Once you register the data as versioned (with move edits to base option) you will have all the data present in the base table. This will allow you use database tools or third party tool on the feature class, however it is not recommended to edit this data using third party tools, try using only ArcMap for this. - If I understand correctly, since you are using third party tools using OBJECTID to maintain referential integrity might not be accurate therefore plan for another field that can be effectively used to relate with all the tables. Having another field (with unique values) I think will be the best way for doing this. - Abhishek ... View more

I see that you are aware about the process of disconnecting users (as you have mentioned that you are trying the same). In case you lack some permissions, you should be getting an error - Insufficient Permissions. Anyway, please look in the following link where apart from the permissions for being a - GeoDatabase Administrator (which includes CREATE SEQUENCE, CREATE SESSION, CREATE TABLE, CREATE TRIGGER, CREATE PROCEDURE)  you will also need to grant - ALTER SYSTEM and SELECT_CATALOG_ROLE. Please refer the following web-link User Privileges for GeoDatabase in Oracle (Common Optional Privileges table) ArcGIS Help 10.1 ... View more

The size of these tables is about 150 MB, I did not have a chance to count the number of records but considering the size i think it is manageable. Since the rate of versions getting deleted is far lower than the rate of versions getting created, the compress gets a huge number in the end_state_count, which leads to a larger size of the database. I think this something, as mentioned, that cannot have pin pointed answer, only textual speculations. Thanks ... View more

Hey Asrujit, Thanks for the information, but I am afraid that we have already referred these technical articles and follow the suggestions of compressing and rebuilding indexes every day. I am trying to run sdegdbrepair -o repair_tables command and today is the 7th day that the command is still running, however I think this is an expected behavior. We are doing this to have the database in the cleanest possible state before upgrading it to ArcGIS 9.3.1 SP2 and apply QIP to it. I am more curious to make sure if it is recommended or safe to have ~2500 versions existing in the production database. ... View more