Latest Contributions by MarcoBoeringa

It was already installed so I'm not sure.  How do I find that information?  There's nothing to indicate it as 64-bit in the Programs and Features list in Control Panel.  I am able to access another server running ArcGIS Server 10.1 without an issue, so I assume that the Microsoft SQL Server 2008 Native Client I have on my desktop is compatible with ArcGIS Desktop.  That could be a faulty assumption. You may try to use the "SQL Server" ODBC driver instead of the "SQL Server Native Client X.X" too, at least if Microsoft has documented it to be able to connect to your SQL Server version, otherwise it won't be of use. However, I can't find it now, but I think I saw a recent thread where someone reported solving his specific issues regarding driver issues by choosing the non-"Native Client" older driver. I also recommend you to have a look at this thread by myself, regarding a Windows 7 ODBC driver issue I had. I don't know if it is a general issue and if it is related to your issues, but it will at least help you find out if you run the 32- or 64-bit driver: http://forums.arcgis.com/threads/70820-BIG-TIP-for-ArcGIS-ODBC-OLEDB-users-on-64-bit-Windows ... View more

Many thanks Macro, I thought that there might be an indicator to show the name of the version and/or user in the table (to know where we are!) Best Jamal Agree, it can be convenient in some cases, although I remember seeing some discussion about IT security / privacy related issues with such an exposure of database user names from within the ArcGIS interface. After all, they are part of the database login. ... View more

To Jamal: I am working on a small PDF file with one figure / diagram that should clear up much of your, and other's, confusion around the "ESRI Geodatabase framework" (if I may call it so...) and all the components / applications involved. I hope to post it tomorrow in the "Why would I install ArcSDE with 10.1?" thread, as there is already a ton of good info by multiple contributors in that particular thread. Stay tuned. Marco ... View more

I�??m wondering why the version and its owner are not shown along with the name of the attribute table. In this case, what is the best practice to distinguish between them? The name of the table is directly derived from the layer name, so if you change the layer name manually to something appropriate upon adding it to the ArcMap TOC (Table Of Contents), you should see different names for tables. ... View more

I'm exploring sdetable -o create_view command making the view as a M:1 and including the shape field so there are geometries for all records.  This works well except views are not editable...is this correct?  Is there a way around this? One additional remark concerning the above statement in your first post: Creating a view should allow you to view the fields of both the base table and the related table in one "view/query" in a 1:M relationship. However, in a sense it is logical you can't "edit" such a view directly, as the view is de-normalized, and the records of the base table have been "virtually" duplicated for each related record in the base table. This older ArcGIS 9.3 Help page also states: "Spatial views contain a single spatial column. You can create spatial views in the same way you create other views; just be sure to include the geometry column in the view definition. The table containing the spatial column must be the same table that provides the row ID (also called the ObjectID) column for the view. Spatial views cannot be edited through an ArcSDE client." And this 10.0 Help page talks about multi-versioned views that can be edited, but only in certain specific situations, and not from within ArcGIS: "Multiversioned views incorporate database views, stored procedures, triggers, and functions to access or edit a specified version of a table or feature class in a geodatabase using SQL." This requires the Table or Feature Class to be versioned, just like the versioned editing of any enterprise geodatabase. And editing from within some custom webapplication or non-ArcGIS (e.g. AutoCAD) application. As that last Help page also states: "The primary use of multiversioned views is to edit versioned data using SQL. You cannot modify the underlying table or feature class through a multiversioned view using an ArcGIS client application." Also, multi-versioned views do not support relationships or joins, they can only be defined for a single Table or Feature Class, see below: "Multiversioned views only work with an individual versioned table or feature class. You cannot use a where clause to join multiple tables together or restrict which rows or columns are included in a multiversioned view." ... View more

Centroids are calculated "on the fly" by ArcGIS and most other GIS/CAD packages based on the coordinates of the polygon, meaning they are not stored as part of the Shape field. I can't tell you why the shape.centroid request returned null on shapes with very small areas, except wrong syntax in scripting (is this for VBScript, with Python, it should be "!Shape!.Centroid" in the Field Calculator) or a bug concerning these small polygons, or invalid geometries. Have you run the Check Geometry tool against both the input datasets and the output that caused the issues? ... View more

another important remark: DBTUNE , SERVER_CONFIG system tables used to be altered using "sde" commands on the database servers. with 2-tier archtiecture the only way to do modifications with them is to install "sde client" on your local PC. I think ESRI should re-consider their design in version 10.1 or at least add the functionality of altering DBTUNE and SERVER_CONFIG using the geodatabase administration GUI interface. It seems likely that more of the geodatabase administration tools will make their way to future releases, but only ESRI can tell when. I agree having to install an ArcSDE application server to modify DBTUNE and SERVER_CONFIG is cumbersome and it should be possible through the ArcGIS GUI. Question is though, for how many setups a modification is really needed. For lesser experienced ArcGIS users / ArcSDE administrators, sticking to the defaults is probably the best option. In addition, if changes are needed to the configuration at all (ESRI undoubtedly has "tuned" the parameters to be optimal for most situations), than this is in most cases a one-time operation taking place during initial setup. This is in contrast to the new 10.1 (ArcSDE) Geodatabase Administration GUI tools that primarily cater for all of the day-to-day or weekly tasks of maintaining a geodatabase. Altering the contents of the DBTUNE table The SERVER_CONFIG system table An overview of the Geodatabase Administration toolset ... View more

I then ran the tool > 'Create Enterprise Geodatabase' I loaded some data into the geodatabase, registered as versioned. When exploring the schema all the SDE and GDB tables are present. Hi Fiona, Good, this means you are most likely "up-and-running", and can start using ArcGIS to fill and use your ESRI geodatabase Am I missing something? Do I need to install ArcSDE 10.1 to get the multi user/versioning/history capabilities of ArcSDE, or as this discussion indicates this is now inherent in the desktop. I still am not 100% clear why I would need to install the ArcSDE application server or command line tools. No, you do not need to install an ArcSDE 10.1 application server to get full geodatabase functionality, including multi user/versioning/history. As I and others have attempted to explain in this thread, ArcSDE's software components in the form of DLLs (Dynamic Link Libraries) form an inherent - and VITAL - part of any "client" ArcGIS application, most prominently "ArcGIS for Desktop" and "ArcGIS for Server" (Server is after all a "client" of the DBMS too, e.g. Oracle, Microsoft SQL Server). They are installed by default as part of the respective software's installation. You can't access or run an ESRI geodatabase without these DLLs that incorporate all the functionality and logic of ArcSDE to handle ESRI geodatabases (at least not by re-doing years long software development by ESRI and at great risk of corrupting the database in case you want to edit something). Like I wrote in my last post: ************************************* ArcSDE is the "engine" of the "car" called "geodatabase"... Take away the engine entirely, and you will grind to a halt. ************************************* However, if this sentence still leaves you confused, think of the ArcSDE application server running on a remote server being "public transport", and the ArcSDE DLLs on your local computer as part of "ArcGIS for Desktop" as your "private car". Both share an "engine" (THIS IS ARCSDE!), but they are independent and both get you from A to B (allow you to access an ESRI geodatabase with all of it's functionality). It is up to you to decide if you want to travel by "public transport" or use your "private car". One mode of transport may be faster than the other (or the other way around), depending on the conditions in your local "area"... To also recap some of the very good comments by the ESRI staff in this thread (Russell Brennan in this case): "Fast forward to 10.1 - We have tried to allow you to manage your Geodatabase completely within ArcGIS applications (ArcCatalog, ArcMap, ArcGIS Server, etc). This is done through the use of dialogues in ArcMap/Catalog and the use of geoprocessing." "If you determine that you really need the application server or the command line utilities they are available as a separate install." These comments mean that only in some exceptional cases, you might need one of the command line tools. Until you run into some serious trouble that really can't be dealt with using ArcGIS's new tools, you should be fine using Direct Connect and leaving your setup as it is now. ... View more

Thanks for the replies. Let me clarify my points further:  1. I know that we have the option to use either 2-tier or 3-tier architecture with Geodatabase Setup. However, in ArcGIS 10.1 Desktop the "  Default" connection type is the   direct connection (without arcsde service credentials (sde port, sde server name,...etc). You still can use your old "application server" sde connections files and ArcGIS 10.1 Desktop will accept them (right click on the connection properties and a new option in the type of connections will be displayed).  The Question is: what's the point of 3-tier architecture (if you upgrade to 10.1),   since all connections Hits are going directly to the database SDE System Tables ?!! They don't necessarily, if you haven't installed Oracle Client, you won't even be able to make a Direct Connection to an Oracle stored ESRI geodatabase... Similar database clients / drivers are needed for the other supported database types if using Direct Connect. Like you say, the choice is an option, but now defaults to Direct Connect. However, this still means you can create a connection file that will connect through the ArcSDE service / application server, and not hit the SDE system tables directly like you say. See this Help topic also: Create ArcSDE Connection File (Data Management) Again, it is an option, I am not suggesting you should run either 3- or 2-tier, the choice is yours and should be based on your knowledge of system usage and available computer hardware (both on the server and local client end). The SDE Geodatabases AP are receiving either (Desktop Connections) or Map Services. if Desktop users have upgraded to 10.1 and your map services MXD's are using 10.1 connection files then there is no need for   ArcSDE Engine anymore. There is no product called "ArcSDE Engine", there is "ArcGIS Engine" (a software component box more or less), and you can run an ArcSDE service / application server process in a 3-tier setup. 3. i don't see any clear documentation in ESRI regarding geodatabase logs in 2-tier setup for ArcGIS 10.1 , what you have provided is for 9.2 release. they should mention it in their documentation in 10.1 !!  Regards, I agree, but at this point, I am not even 100% sure there haven't been changes in the logging between 9.x and 10.x. It is not very likely, but if you have your setup running with 10.x, you could check for the existence of the ArcSDE log files on your local computer using the 9.x Help instructions of where they might be stored. I don't have a setup running at this moment, so can't check it for you. ... View more

2. is there any logs will be generated with 2-tier architecture for the geodatabase (where can i find them) ? previously, using ArcSDE as an application server we would find SDE logs being generated on the database server file system. I don't know if it changed from 9.x to 10.x, but this 9.x Help page states: "ArcSDE writes error messages to the following two log files when using direct connect: giomgr_<service>.log file and sdedc_<dbms>.log. If you have the SDEHOME environment variable set, these files will be written here. If you have an etc folder in your ArcGIS installation location, the files will be written here. If you have neither of these, the log files are written to the temp directory." ... View more

You may also find the following forum thread of use: Why would I install ArcSDE with 10.1? ... View more

Hi, if i want to re-design my current infrastructure from 3-tier to 2-tier Geodatabase infrastructure. (Since 10.1 released ESRI ArcGIS Suit is using direct-database connections) This is a misconception, you can still run a 3-tier architecture with a separate ArcSDE service application running on your database server at 10.1. You can convert to 2-tier if you want, but it is no requirement to upgrade to ArcGIS 10.1. You just have to evaluate if in your situation a 2-tier direct connection gives any benefits. It may not be worth the effort just doing it without considering potential benefits and drawbacks (like the need to install Oracle Client software to facilitate a 2-tier direct connection to Oracle). ... View more

Good to see you choose to use the "arcpy.ChangePrivileges_management" tool instead of the unwieldy road of attempting to solve the issue straight at the database level using SQL, which would probably have ended up in a mess with wrong privileges set on crucial geodatabase tables. As Vince and Leo already said, having ArcGIS or arcpy manage all the SQL logic involved in geodatabase (privilige) management is best practice. ... View more