Latest Contributions by MarcoBoeringa

OK, I now think I have gotten one step further with this. It appears the order of commands described in the Help topic "Editing versioned data in SQL Server using SQL" is incorrect, or that the ArcSDE stored procedure "SDE_getglobals" falsely doesn't allow you to set the current version when not in edit mode (at least in SQL Server, I don't know in other RDBMSs). In addition, it appears any set version, only applies to the current active Transact SQL window, meaning you can't use it to change the way the view appears to the world outside SQL Server Management Studio (e.g. in Quantum GIS). Other applications accessing the Versioned View will only see the DEFAULT. Probably not entirely illogical, as setting the version as a kind of global for the entire database, would cause all users connected to the same Versioned Views to see the same version, and get confronted with subsequent changes. It needs to be user tied, or in this case limited to the context of the Transact SQL window. It essentially means that edits against a specific version of a Versioned View is only supported straight in the Transact SQL command window, otherwise the ArcSDE C/Java API or ArcObjects is required, like for example the FDO Provider for ArcSDE in AutoCAD Map 3D does (uses C API) that does allow version switching on a user connection basis. According to the Help the order of the commands is: 1) Open a Transact-SQL query window and execute the create_version procedure to create a named version in which to perform your edits. EXEC sde.create_version 'sde.DEFAULT', 'myedits12111', 1, 2, 'version for my mv edits'; 2) Set the version for the edit session to the child version you just created. EXEC sde.set_current_version 'myedits12111'; 3) Start an edit session by executing the edit_version stored procedure and specifying 1. EXEC sde.edit_version 'myedits12111', 1; However, I discovered the "sde.setcurrent_version" command fails and returns -1 for the version_id if NOT IN EDIT MODE already, even though the command is reported back as having run successfully. This means you must run the text line: EXEC sde.edit_version 'myedits12111', 1; before running: EXEC sde.set_current_version 'myedits12111'; E.g. if I enter (please note my ArcSDE is "dbo" owned, replace with "sde" if SDE owned): EXEC MyDatabaseName.dbo.set_current_version 'MyUser.MyVersionName' than this fails... If I enter: EXEC MyDatabaseName.dbo.edit_version 'MyUser.MyVersionName', 1 EXEC MyDatabaseName.dbo.set_current_version 'MyUser.MyVersionName' EXEC MyDatabaseName.dbo.edit_version 'MyUser.MyVersionName', 2 with a start and end of an edit session, the command does run successfully. How do I know this? Well, first I entered some debugging code in the stored procedures for the "set_current_version" and "SDE_set_globals" and "SDE_get_globals". The results show the version_id is returned as a false -1 if not in edit mode, but the correct version_id for the "MyUser.MyVersionName" version if IN edit mode when setting the version. In addition, I added a SELECT statement against the Versioned View in the same Transact SQL window, and the result showed the correct, NON-Default, version data with all the edits I did. E.g.: EXEC MyDatabaseName.dbo.edit_version 'MyUser.MyVersionName', 1 EXEC MyDatabaseName.dbo.set_current_version 'MyUser.MyVersionName' EXEC MyDatabaseName.dbo.edit_version 'MyUser.MyVersionName', 2 SELECT * FROM MyDatabaseName.MyUser.MyDatasetName_VW does show the proper Spatial Result of the Versioned View in SQL Server Management Studio. ... View more

I downloaded a utility to monitor SDE activities but for some reasons it gives error (see attachment). Have I missed something during installation? Please assist. If you mean SDEMonitor, it is almost a certainty this tool is unusable with any current version of ArcSDE and ArcGIS. The last update I see is version 3 from 2004... You really need to look at for example the new 10.1 Geodatabase Administration tools for some of this functionality in GUI form. It is not a replacement for specific functions of SDEMonitor regarding Application Servers, but might fullfill some of your needs. A quick tour of administering ArcSDE geodatabases with ArcGIS for Desktop An overview of the Geodatabase Administration toolset ... View more

Don't know how to interpret this yet, but if I insert a: -- BEGIN EDIT DECLARE @i int SET @i = @g_version_id SET @error_string = 'g_version_id: ' + (SELECT LTRIM(STR(@i,10))) RAISERROR (@error_string,16,-1) -- END EDIT just before the last code lines in the set_current_version stored procedure (before the comment line "-- Finally, set the global info"), than the "g_version_id" comes up as -1. It should be 2 for the version I set if I look in the "dbo.SDE_versions" table... ... View more

Hmm... I now found this thread mentioning at least one known relatively recent (2012) issue with the set_current_version stored procedure (or the other functions it calls), although that thread mentions it being related to DEFAULT: http://forums.arcgis.com/threads/51244-Multi-versioned-Views-Not-seeing-data-in-the-A-amp-D-tables?highlight=set_current_version Still a real possibility there is an issue with my arcsde or geodatabase system tables, maybe related to the QGIS edit, but I don't see it at this point going through some of these tables (just a few records, since it is a small test database). ... View more

Hello, I am trying to set current version in SQL server using the stored procedure: EXEC sde.set_current_version 'DBO.residence' But it doesn't seem to work because when I check my MV view, it seems to be referencing the DEFAULT version still. Has anyone encountered this problem or know what the solution is? Thanks, Reuben I recently ran into similar issues with SQL Server. I have a small test setup and test database using SQL Server Express with one versioned feature dataset with a few feature classes.. My instance is SQL Server 2012 Express SP1 upgraded from SQL Server 2008 R2 Express SP2, using ArcGIS 10.1 SP1. My database is DBO owned, and I can see the set_current_version stored procedure as dbo owned. I also tried to set the current version of a multiversioned view, but kept getting the DEFAULT (which is still at state 0). I ran the code snippet below (which comes straight from the versioned view code except for replacing "SELECT l.lineage_id" with "SELECT s.state_id"), that returns the state after running the set_current_version command (you can modify it to show lineage_id as well). It consistently returned state 0 after running the set_current_version command, while the version I tried to set has state 12. The set_current_version procedure ran successfully according to the message displayed in the SQL Server Management Studio status window. Change dbo/sde in the snippet to either dbo or sde depending on who owns it: SELECT        s.state_id     FROM            YOURDATABASENAME.dbo/sde.SDE_states s INNER LOOP JOIN                                 YOURDATABASENAME.dbo/sde.SDE_state_lineages l ON l.lineage_name = s.lineage_name     WHERE        s.state_id = YOURDATABASENAME.dbo/sde.SDE_get_view_state() AND l.lineage_id <= s.state_id In my case, the version pointing to state 12 is also another user than dbo, who owns the default. The non-dbo owned version I tried to switch too from the default owned by dbo, is set "public". I haven't been able to figure this one out yet looking at things like the contents of the SDE_versions, SDE_states, SDE_states_lineages tables etc. I must admit I did make an edit through Quantum GIS (QGIS) against the multiversioned view, before actually attempting to set a version through SQL Server Management Studio and the set_current_version command. But this should not necessarily cause issues, the multiversioned views are designed for this purpose. I did notice one issue though where ArcGIS did not recognize the proper extent of the total dataset (it did display the new polygon, but didn't properly zoom out to it). This was solved with another edit in ArcMap itself, which seems to have updated the layer's extent. QGIS also consistently shows state 0, the same if I look at the "Spatial results" window in SQL Server Management Studio. ... View more

I can say that the people administering this SQL Server are pointing to ESRI as the problem because they cannot log into the renamed geodatabase using the logins/passwords that the original production sde geodatabase had and they think that ESRI security is causing the problem.  I don't even know how to respond to that. ESRI geodatabase security = RDBMS security = (most likely in case of SQL Server) Windows Authentication So if you can't login after recreating your database and nothing else changed, you've taken the wrong path (as Vince already told you: you can't rename the database with an established geodatabase in it). The path you probably should take if you really need to "rename" (note the quotes): 1) - Create a new database using the new name in your instance (or if desired an entire new instance) 2) - Re-create any database users / roles etc. of the old database you wished to "rename" in the new database 3) - Use the "Enable enterprise geodatabase" tool to create a new ArcSDE Repository in the new geodatabase (Alternatively you could have used the "Create enterprise geodatabase" tool to do steps 1 and 3) 4) - Copy over any datasets (Feature Datasets / Feature Classes) from the old geodatabase to the new one, or use One-Way Geodatabase Replication to do it. There may be some headaches here, especially if there are outstanding versions and editing is going on. See also Understanding distributed data Vince can probably give you more details and correct/supplement what I wrote. ... View more

I understand.  I was hoping to confirm that your DGNs are read correctly.  I can tell you that in the upcoming release, my test cases of DGN BSplines work correctly. You are probably already familiar with this, but this older thread has some more detailed info about B-spline issues (e.g. see remark Ray Carnes - ESRI Technical Marketing) and some test datasets: http://forums.esri.com/Thread.asp?c=93&f=982&t=266100 ... View more

Jamal, Any users not allowed to export data, should probably not be using ArcGIS for Desktop at all... there is just to many access points to data and tools for data conversion. Instead, they probably should be using some custom web-application to access non-editable ESRI Image or OGC WMS services serving out just images and not true features. By the way: you can access these webservices too through the ArcMap interface. This might be a part solution: make the Feature Classes only directly accessible to the geodatabase administrator, and than create ESRI Map / Image or WMS webservices using ArcGIS for Server to allow access to other users from within ArcMap. If the users do need editing capabilities, than a custom web editing application using ESRI Feature Services or OGC WFS-T (transactional WFS) might be in order, but that would still allow access to feature geometry data somehow, but at least not directly from an interface like ArcGIS for Desktop with its many options... ... View more

To confirm, a direct connect is sufficient for a feature service - as long as the database supporting the feature service has the SDE tables within it, correct? Karyn, ArcGIS for Server is, just like ArcGIS for Desktop, fully capable of using both an ArcSDE Application Server, or Direct Connect, for connecting to an enterprise geodatabase. From a functionality point of view, there is absolutely no difference between using an Application Server or Direct Connect. So yes, "Direct Connect" is sufficient for ArcGIS for Server to create (editable) Feature Services. ... View more

As far as I understood it from reading the Help pages (I haven't a setup running now), the whole point of the Web Adaptor was integration with your web server security model and hiding the GIS Servers from direct access. Maybe some others with real experience can give better directions. ... View more

With SDE, I guess you mean you are contemplating installing an ArcSDE Application Server? Note ESRI currently pushes for Direct Connect as the default connection method to a geodatabase, eleminating the need for installing an ArcSDE Application Server. This doesn't mean you can't install and run one, but be aware of this. Also note the standard "Database Connections" option in ArcCatalog at 10.1 no longer supports connecting to an Application Server. You will need to use the new specific "Create ArcSDE Connection File" tool for that. See this Help topic: Making an ArcSDE service connection from ArcGIS As to the question of running the Application Server from another server than the database server, unless you run a >= 10Gbit ethernet network connection between the servers, your Application Server will likely be limited by the network bandwidth. Even a single modern 7200 harddisk of an ordinary desktop computer can throughput over 160-180MB/s (not even talking about server RAID configurations), which equates to over 1,5Gbit/s, which means a 1Gbit (or worse) ethernet connection may prove a bottleneck. ... View more

It sounds to me that maybe some vital field indexe(s) may have been corrupted. Have you tried re-indexing? I am not to familiar with the specifics of SQL Server, but this Microsoft MSDN page: ALTER INDEX (Transact-SQL) may be of Help. It seems a "ALTER INDEX ALL ON YourTableName REBUILD" or something similar might be in order (or an equivalent menu option from SQL Server Management Studio), but maybe some SQL Server experts here on the forum can give better specifics for recovery... ... View more

Before trying to re-invent the wheel, I think you should look at the ESRI ArcGIS for Aviation product. It has tools for creating and visualizing obstacle surfaces: ArcGIS for Aviation: Key Features ... View more

1) ArcSDE doesn't use UDP, so there's no reason to have duplicate service name entries Vince, this was my understanding always too, but looking at the 10.1 Help regarding Starting a remote ArcSDE service on Linux or UNIX, I now read this: "2. As the root user, duplicate the service name in the /etc/services file as a User Datagram Protocol (UDP) entry that uses the same port number on both the local and remote servers. # \etc\services esri_sde 5151/tcp esri_sde 5151/udp 3. As the root user, update the /etc/inetd.conf file. Add this line to the bottom of the file. <ArcSDE instance> dgram udp wait <owner of ArcSDE home> <$SDEHOME>/bin/sderemote iomgr_inetd <$SDEHOME><ArcSDE instance>" The UDP connection seems necessary for running the ArcSDE service from a remote server, so in case it is installed on a physically separate server from the database server it uses the data from, as written on this Help page. P.S. Just to clarify for other Forum users reading this thread... ... View more

2. Now, publishing this amount of images (around 6.38 GB in total) is not an easy job. Then I�??m wondering if there might be better approach to be able to publish these images with optimal time Jamal, Could you be a bit more specific as to why "publishing this amount of images... is not an easy job"? Is the problem with the publishing of the service itself? Is it taking excessively long? Or is the problem actually not related to the publishing process, but are you merely unsatisfied with the ECW services performance as a web service when accessed from the internet? These are two different problems... In case of excessive publishing times, you definitely should check out if ArcGIS for Server is accessing the data directly (as it should), or if the publishing process is actually creating uncompressed copies of the data on the server where ArcGIS for Server runs. This could be a huge penalty with something as highly compressed as ECW, even clogging up your entire server's hard disk space. You should make sure ArcGIS for Server uses the data directly as the ECW format it was stored in, which is the whole purpose of buying the ECW for ArcGIS for Server product. In case of inadequate performance of the created web service, how does accessing the data directly from ArcMap perform? Are your file servers up to the task of serving this data? There are several other options offered by ArcGIS for Server, most notably though, the ones offering tiling schemes, cutting up your data in small pieces and predefined pyramid zoom levels, to ensure maximum performance. Read the ArcGIS for Server Help pages for the options. Be aware though, that most of these options will require a decompression of the original data and only very limited re-compression to another format compared to ECW. The penalty in file size increase may be unacceptable in some cases. ... View more