Latest Contributions by MarcoBoeringa

1. I expect that feature #11 must be updated based on u3 (blue color) and thus THE SPATIAL LOCATION SHOULD GO TO THE �??BLUE�?� COLOR NOT TO THE RED Jamal, you are still missing a point here, and I explained this in my last post. This is what is happening for feature 11: 1) Since in these last screenshots you posted, you don't edit feature 11, feature 11 isn't in conflict with u1. This means the edit of u1 will be posted to target SDE.DEFAULT. 2) Next u2 will be reconciled against target SDE.DEFAULT. Since feature 11 in SDE.DEFAULT now changed based upon the edit in u1, it now IS in conflict with feature 11 in u2! Since you set "FAVOR_TARGET_VERSION", the edit in u2 will be ignored and SDE.DEFAULT remains the same. 3) The same holds for u3, feature 11 in u3 is in conflict with the target SDE.DEFAULT, and hence the edit of feature 11 in u3 will be ignored / discarded too. As a consequence, feature 11 in SDE.DEFAULT will be based on the edit of u1. You will need to set "FAVOR_EDIT_VERSION" in case you want the edit of feature 11 in u3 to be incorporated in target SDE.DEFAULT. As you can now also see, the status of being "in conflict" or not, can change during the batch reconciliation, as each edit version is reconciled and posted one after another... ... View more

Except that the diagram is wrong.  It should look like this: Client (ArcObject, ArcCatalog, ArcGIS Server, ArcIMS...)       |       |--------> Application-level debugging and logging      \|/ ArcSDE Client API       |       |--------> SDE Trace      \|/ ArcSDE Server --> ArcSDE Service Logfile, or direct connect log       |       |--------> SDE Intercept      \|/ DBMS-----------> DBMS logfiles or trace       - V OK, thanks for the important correction. Actually, I was already slightly confused about the positions of the SDE Trace and SDE Intercept in the diagram, but your corrections, including adding "API" to the ArcSDE Client API component of the diagram, clarifies it. ... View more

I prefer to use the SDETRACE environment, which captures the session at the ArcSDE API level (between client and server), vice the SDEINTERCEPT environment, which captures interaction between the server and the database. You may find the following link from GIS StackExchange useful to better understand what Vince means with above quote. Especially have a look at the remark by Travis: How to trace SQL queries sent by ArcGIS Server (ArcSDE) to Oracle database? http://gis.stackexchange.com/questions/61776/how-to-trace-sql-queries-sent-by-arcgis-server-arcsde-to-oracle-database And possibly this ESRI Blog and Knowledgebase article (*warning*, depending also on your browser settings, right clicking the Blog link may not take you to the Blog article itself but the main index, use left click instead): Blog: Why should I be making direct connections to an ArcSDE geodatabase? Knowledgebase: HowTo:  Diagnose ArcSDE connection and performance issues using SDEINTERCEPT ... View more

To be honest, I have never used subtypes in real-life, so its getting a bit theoretical here, but I am pretty sure subtypes can't be "nested". So you will have to adjust your geodatabase design to accommodate for this limitation. E.g. by creating separate Feature Classes for the different fields you want subtypes on. ... View more

Many thanks Marco for the massive elaboration, Please, consider the scenario in the screenshots below The target geodatabase is editied (in the post stage) despite the fact that the �??conflict resolution�?� is set based on �??target version�?� Jamal, if by this, you mean you hadn't expected feature 11 to move in SDE.DEFAULT because you set "FAVOR_TARGET_VERSION", than you are forgetting that you didn't edit feature 11 in the SDE.DEFAULT, you only edited feature 11 in the versions u1, u2 and u3. Since you didn't edit feature 11 in SDE.DEFAULT, there is NO edit conflict for feature 11 between SDE.DEFAULT and u1 once you start reconciling. Hence the edit of feature 11 in version u1 is posted to SDE.DEFAULT, and feature 11 thus moves in SDE.DEFAULT. If you want to see the other result as a test, namely a feature 11 that does not move with the edits in other versions, you will need to create a conflict by editing it in the SDE.DEFAULT as well, and setting "FAVOR_TARGET_VERSION", and than reconcile and post. This is what you did with feature 10, you moved it in SDE.DEFAULT. As a consequence, feature 10 in SDE.DEFAULT is in conflict with u1, and since you set "FAVOR_TARGET_VERSION", feature 10 remains as it is in SDE.DEFAULT after the reconciliation and post. ArcGIS is behaving exactly as expected! ... View more

- You don't need to install an ArcSDE Application Server (Also called "ArcSDE service" in ESRI documentation) if you want to connect to your geodatabase, use Direct Connect instead. The ArcSDE Application Server will no longer be available after ArcGIS 10.2, so it is highly recommended to switch to Direct Connect at this point in time. - You may need an ArcGIS for Server installation if you use it to create webservices (ESRI Map, Image, Feature Services or WMS, WFS or any of the other service types it supports). If you're not interested in serving your own webservices, you don't need ArcGIS for Server. - Use the new geoprocessing tools in the Geodatabase Administration toolset in ArcGIS for Desktop for management and creation of your ESRI enterprise geodatabase. See for example the Blog article by ESRI's Melissa J linked below, and the second link to the Geodatabase Administration toolset: Do This, Not That! �?? Alternatives to using SDE command line tools: http://blogs.esri.com/esri/supportcenter/2013/10/04/do-this-not-that-alternatives-to-using-sde-command-line-tools/#sthash.YiYFmz5c.dpuf Geodatabase Administration toolset An overview of the Geodatabase Administration toolset You may find it helpful to read these two PDF documents I created: The ESRI Geodatabase Framework http://forums.arcgis.com/threads/83644-quot-The-ESRI-Geodatabase-Framework-quot-PDF?p=295462&viewfull=1#post295462 The ESRI Geodatabase Framework - Future developments at ArcGIS 10.2 and 11 http://forums.arcgis.com/threads/83644-quot-The-ESRI-Geodatabase-Framework-quot-PDF?p=303021&viewfull=1#post303021 ... View more

Al, what version of ArcGIS and ArcSDE are you running? If also still 9.2, it is highly recommended to upgrade A.S.A.P. ESRI will even stop supporting 9.3.1 SP2 in the near future, so any potentially necessary - intermediate step - upgrade path via 9.3.1 to 10.x will become even more difficult soon, as you won't be able to request regular support from ESRI even for 9.3.1 when it will be retired at the end of this year. See the Product Life Cycle PDF: http://downloads.esri.com/support/product%20life%20cycle/server_gis/ArcGISServer_PLC.pdf This really sounds like an issue to take up with ESRI Tech support if you are on a supported platform... ... View more

For those ArcSDE Admins who either have never used the GDBT toolset, or those who are already in the 10.2 environment: how do you check for full compression, conflicted versions, orphaned replica versions, etc., and with what regularity?  Thank you! Hi Marianne, I realize this is not a full answer to your questions, but I recommend you to have a look at this recent ESRI's Support Service Blog article by Melissa J.: Do This, Not That! �?? Alternatives to using SDE command line tools - http://blogs.esri.com/esri/supportcenter/2013/10/04/do-this-not-that-alternatives-to-using-sde-command-line-tools/#sthash.undVSxSk.dpuf ... View more

Sorry Jamal for causing more confusion, but I made a serious error in post 13 when I attempted to describe what is happening. It doesn't influence the end result though (u1 edit being favoured over other edits), as the cause of your issue remains the same, favouring the target version in case of a conflict, instead of favouring the edit version. You need to change your settings in the "Reconcile Versions" toolbox dialog if you want other results. See below for the explanation. ArcGIS determines the recommended reconciliation order based on the save times of the edits. In your case, the dialog shows that ArcGIS will perform three reconciliation and post cycles, in the following order starting at 1) and ending at 3). 1) u2 <--- u3 2) u1 <--- u2 3) target <--- u1 This part of what I wrote in post no. 13 isn't correct. It is only correct if u3 was deliberately reconciled against u2, u2 against u1 and u1 against SDE.DEFAULT (in your example). You showed in the screenshot the reconcilation to follow the path: 1) target <--- u1 2) target <--- u2 3) target <--- u3 So in reality, all versions in a "batch reconcilation" action are reconciled and posted against the target directly (SDE.DEFAULT in your case). Still, this doesn't change things as far as the results, as you chose "FAVOR_TARGET_VERSION". Since u1 is reconciled and posted first, the edit of point feature 11 in u1 will take precedence over edits to the same feature 11 in versions u2 and u3. The edits therein will be ignored and not posted to the target SDE.DEFAULT. This is what I see happening in your screenshots. How the order can be (so that the edits of u2 are taken): 1. reconcile from sde to u2 and then post from u2 to sde 2. reconcile from sde to u3 and then post from u3 to sde 3. reconcile from sde to u1 and then post from u1 to sde [ATTACH=CONFIG]28079[/ATTACH] If, by this, you mean the edits of u2 should be favoured over u1 because they were saved the latest, you need to change the "conflict_resolution" parameter from "FAVOR_TARGET_VERSION" to "FAVOR_EDIT_VERSION". Choosing FAVOR_EDIT_VERSION will mean that in case of a conflict (and feature 11 from u2 is in conflict with target "SDE.DEFAULT" when the edits of u1 are already posted in the first reconcilation and post step), the edit version will take precedence over the target version, meaning the edit of feature 11 in u2 will be posted to target SDE.DEFAULT, "overwriting" the previously posted edit of u1. ... View more

According to this article, http://resources.arcgis.com/en/help/main/10.1/index.html#/ST_Transform/006z0000009s000000/, to apply file-based CRS transformation in using sde.st_transform function, need to copy the ArcGIS pedata folder to the database server and setup environmental variable PEDATAHOME on the database server. It gives an example for databases on Windows. I am wandering if anybody has done this for SDE database on Linux and what else needs to be done. Does the database instance needs to be rebounced or the listener needs some extra configuration? Reading that link you provided, I doubt any extra configuration is needed compared to a Windows server. It just reads: "Refer to your operating system documentation for information on how to set an environment variable." as a special note regarding setting the PEDATAHOME environment variable on any operating system. There is no hint of extra configuration, besides copying the PEDATA folder and its containing files and subfolders as on all systems. Why don't you give it a try? The Help seems to provide a set of full working pieces of sample codes to test it out and know if it functions under the Transforming data when the source and destination spatial references do not have the same geographic coordinate system (Oracle only) heading. ... View more

I tried the patch and it did not have any effect on my Oracle installation. It's for PostGIS? Looking at the installed files, even though PostGreSQL is specifically mentioned in the title of the patch, this patch also seems relevant for Oracle, as files for the other DBMSs are installed as well. Fixes for the other DBMS are related to Parcel Editing. Do mind the caveat though (see the patch link😞 "If you installed the ST_Geometry type in your Oracle or PostgreSQL database, upgrade the type after you install the ArcGIS 10.1 SP1 for (Desktop, Engine, Server) PostgreSQL and Parcel Editing Performance Patch. See the topic specific to your DBMS for instructions: ..." ... View more

I may not be telling something new, but you will need ArcGIS for Server for this, and setup a Geoprocessing Service. Two entry points most relevant in the Help are probably: What is a geoprocessing service? An overview of geoprocessing REST Services ... View more

Many thanks Marco. U2 version is derived directly from the default version. The tree is shown on the screenshot below: [ATTACH=CONFIG]27938[/ATTACH] Thanks for the answer, but I realized it is actually irrelevant here. What IS relevant, is the reconcile order shown in your screenshot (target <--- u1 <--- u2 <--- u3), and the fact that you chose FAVOR_TARGET_VERSION. Very confusing! I expect that the updates of feature #11 will follow the u2.u.2 version (since the most recent edits occurred there) while the updates of feature #9 will follow the version u1.u1 (since the last edits occurred there) What is confusing that the both conflicts are updated based on the u1.u1 version! How come the u1.u1 is the determinant? I tried to do other conflict changes and found out that the updates of the u1.u1 are considered! What might be the issue here? "What might be the issue here?" There is no issue here, ArcGIS is behaving exactly as expected, and as you yourself ordered it to do! "How come the u1.u1 is the determinant?" This is because you ordered ArcGIS to resolve conflicts in favour of the target version, by setting FAVOR_TARGET_VERSION in the geoprocessing dialog. What you have to realize is that the list of edit versions shown that will be reconciled, is not an arbitrary list, it is ordered in the sequence the versions will be reconciled against each other. If you perform batch reconciliation, versions are always processed in pairs of two: one target and one edit version. So even though you have 3 edit versions here, only two of them are reconciled and post at a single point in time during the batch reconciliation. ArcGIS determines the recommended reconciliation order based on the save times of the edits. In your case, the dialog shows that ArcGIS will perform three reconciliation and post cycles, in the following order starting at 1) and ending at 3). 1) u2 <--- u3 2) u1 <--- u2 3) target <--- u1 As you can see, u3 will be reconciled and post first against target u2, than u2 against u1, and finally u1 against the main target (SDE.DEFAULT in your case). Since you chose BY_OBJECT and FAVOR_TARGET_VERSION, any conflicting edits in u3 and u2 will be dropped(!) (remember you learned this from my post in the other thread you started). This is exactly what is happening: You created a conflict by moving point 11 in both version u2 and u1: a. Feature #11 stays the same in the sde.default b. Feature #11 is moved to left in version u1.u1 and saved c. Feature #11 is moved to right in version u2.u2 and saved Since the target version in the reconcilation of step 2) u1 <--- u2 is version u1, and you chose to favour the target, the edit of u2 is dropped, and the u1 edit remains:  "b. Feature #11 is moved to left in version u1.u1" Since this edit b. is not in conflict with SDE.DEFAULT, it is reconciled and post to target version SDE.DEFAULT in the next step: 3) target <--- u1 And as you see and hopefully understand now, the edit of u1 takes precedence over the edit of u2, as you ordered ArcGIS to do by setting FAVOR_TARGET_VERSION. ... View more