Latest Contributions by AsrujitSengupta

‎01-25-2013

Ernst, The respective F-table maintains the shape.len and shape.area information for a Feature Class. But as Vince mentioned, it's not possible to implement this always. The "F" table does not always exist. Native geometry types do not include a Shape.Len and Shape.Area field. We can't create them using an OLE DB connection. These queries can be used to query the details though, from my experience (sde.Area3 is the FC name): Select shape.STLength() as length from sde.Area3 Select shape.STArea() as area from sde.Area3 Regards,

‎01-24-2013

Nicholas, Here is a link to download the ArcSDE 10.1 SP1: http://support.esri.com/en/downloads/patches-servicepacks/view/productid/66/metaid/1914 Regards,

‎01-18-2013

Erik, Simply stated, you'll have to recreate the Replica to populate data in the new fields. Regards,

‎01-11-2013

Jamal, You don't have the option to uninstall Oracle dadatabase from Control Panel. It can be done using the Oracle Universal Installer (See the screenshot) [ATTACH=CONFIG]20661[/ATTACH] You can have a look at various links on Oracle and other sites detailing these steps too. E.g.: http://www.dba-oracle.com/t_uninstall_software.htm http://oracle.su/docs/11g/install.112/e10854/remove_oracle_sw.htm http://www.emarcel.com/database/114-uninstalldb11g Regards,

‎01-09-2013

Another way of portraying this can be that, the "sde" user and its password is set at the SQL Server Instance level....so all the databases under that instance are supposed to follow the same credentials.. Regards,

‎01-07-2013

Matt, You can look at the following links for the system tables information in 10.1: Oracle: http://resources.arcgis.com/en/help/main/10.1/index.html#//002n0000008m000000 SQL Server: http://resources.arcgis.com/en/help/main/10.1/index.html#//002q00000080000000 I guess the GDB_Replicalog table should provide you with the necessary informations. Regards,

‎12-27-2012

Mike, You can refer to this link. It might help: Example: Discovering domain usage using SQL http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//006z000000t9000000 Regards,

‎12-26-2012

Charles, This link could be an answer to what you are looking for: Why do shapefiles draw faster than file geodatabase feature classes in some instances? http://support.esri.com/en/knowledgebase/techarticles/detail/37719 File Geodatabases are preferred to shapefiles due to multiple reasons and not just speed, some of which were pointed out by Vince. Regards,

‎12-20-2012

As a workaround, you can move the Feature Classes out of the Feature Dataset, upgrade the precision of Feature Classes and Feature Dataset using the 'Upgrade Spatial Reference' tool. Then move Feature Classes back inside the Feature Dataset. Or you can simply copy your data into a File Geodatabase (this will convert them into High Precision) and back into the sde geodatabase. But, as Craig mentioned, you should contact ESRI Technical Support so that they can troubleshoot this issue properly. Regards,

‎12-20-2012

Hi Paul, You might want to take a look at these links: http://zacster.blogspot.in/2007/09/create-or-rebuilding-oracle-spatial.html https://forums.oracle.com/forums/thread.jspa?threadID=2433630 Regards,

‎11-19-2012

Leo, In this thread we were talking about a "Feature Class" and not a feature. The concept would be completely different for the two. Yes, while Reconcile/Post we can manually look at the conflicts and decide in favor of the Parent version, but for that to happen the feature should have been modified in both the versions....or else it will simply overwrite depending on what you chose(edits in favor of Child\Parent). As for the other question, YES...it will remain in the replica geodatabase untill you synchronize. Regards,

‎11-19-2012

Sandy, I would say "Cold Backup" is the safest way to back up because it avoids the risk of copying data that may be in the process of being updated. However, a cold backup involves downtime because users cannot use the database while it is being backed up, so it basically depends on your workflow. As you mentioned RMAN, I'm guessing that you are using Oracle DBMS. I can't really say about the RMAN much as I'm not familiar with it, as much as the other two. But as far as I understand RMAN uses the same HOT(online) & COLD(offline) backup methods. So go for RMAN Offline Backup..;) Regards

‎10-24-2012

Hi Carmen, You can verify the version of your sde geodatabase from the "SDE_version table" at the back-end. It is a system table containing the version information related to that geodatabase. Here is a link for the various system tables in a SQL geodatabase: http://resources.arcgis.com/en/help/main/10.1/index.html#//002q00000080000000 I am unable to tell whether the GDB that was created has 10.1 capabilities or 10.0 capabilities (when I can determine this with our SDE Enterprise DB) You cannot create a Enterprise GDB with a combination of sde 10.1 and ArcGIS Desktop 10.0., as sde 10.1 doesn't have post installation wizard and ArcCatalog 10.0 didn't have the capability of creating enterprise geodatabse. If you were indicating to your previously created sde gdbs, you can check that using the 'SDE_version table' as mentioned earlier. Basically if all your users (client 10.0 or 10.1) are connecting to the SQL Server 2008 R2 Instance which was enabled using sde workgroup 10.1, and creating a sde gdb...all of them will have the sde 10.1 features and capabilities! The client in this scenario won't matter, the version of sde will. Regards, Asrujit

‎10-22-2012

Hi Carmen, This geodatabase matches the ArcGIS release you are currently using I am just guessing this from your initial post, but I think that you have created the geodatabase using ArcSDE Workgroup 10.1. So this message in ArcCatalog 10.1 is as we expect. This 10.0 database matches the ArcGIS release you are currently using Now my guess is, as the geodatabase was created using ArcSDE Workgroup 10.1, the ArcCatalog 10.0 cannot upgrade it any further as it is already on an above level. So it throws that message in the properties, somewhat misleading but true. All this is assuming you had used ArcSDE Workgroup 10.1. So, correct me if I have got that part wrong. Regards, Asrujit

‎10-18-2012

"The "in_memory" workspace is not supported as the output location." sometimes occur if the Geodatabase has similarly named feature classes, etc... You can't copy the Feature Dataset from the FGDB into the Feature Dataset in the sde geodatabase, as that is not supported. I tried the same workflow that you were following initially, and the copy/paste was successful. (Just copy the geometric n/w from the fgdb dataset into the sde dataset).

Online Status	Offline
Date Last Visited	‎11-11-2020 02:23 AM

My Ideas

Latest Contributions by AsrujitSengupta

Re: Shape.Area and Shape.len via ODBC

Re: ArcSDE Service won't work with PostgreSQL 9.1/PostGIS 2.0

Re: getting data into replica gdb from parent gdb

Re: How to uninstall the �??oracle�?� database?

Re: Database /Geodatabase administrator password,

Re: Does the SDE.GDB_REPLICA table exist in 10.1?

Re: Which domain get associated with which field and feature class

Re: Is File Geodatabase Really Faster than the Shapefile?

Re: Problem Upgrading Spatial Reference for certain Feature Datasets

Re: Spatial Index error creating new feature classes in Oracle 11g r2 ArcSDE 10 sp5

Re: Retrieving a feature class which was deleted from child version.

Re: Retrieving a feature class which was deleted from child version.

Re: SDE for Workgroup: Upgrade Status for Geodatabase info confusion between 10 and 1

Re: SDE for Workgroup: Upgrade Status for Geodatabase info confusion between 10 and 1

Re: Cannot copy a geometric network from one geodatabase to another

Re: Failure to “post” changes from child versions ...

Re: Tables participating in a replica generated em...

Re: Database Username and Schema do not match

Re: Detect Feature Change 10.3

Re: Having trouble refreshing a version