Latest Contributions by WilliamCraft

Is sql2008r2 your instance name?  Try changing your -i parameter to include only the hostname... -i sde:sqlserver:hostname ... or try separating them without specifying the SQL Server instance name ... -i sde:sqlserver -s hostname ... View more

Good morning All, I got a sql spatial database from our client. I found their version is 10.0 but ours is 10.1. So I created a direct database connection in ArcCatalog and upgraded the geodatabse. Afterward, I went back to SSMS to check the AUTH_KEY in SDE_server_config table. The license is still 10.0 in the cell. I run the "sdesetup -o update_key" command line where the SDE SERVER is sitting. I got an errors saying: Failure to access the DBMS server (-409). Error upgrading authorization key. Can anyone help? Thanks! -yl A few questions... Are you referencing a 10.1 keycodes file when running the sdesetup -o update_key command?  For the -i parameter in the sdesetup command, are you using an ArcSDE service or a direct connection?  It might be helpful to post the entire command you are running (minus the SDE password) so we can see the connection you're trying to pass.  After the upgrade completed, can you still connect to the 10.1 GDB via ArcCatalog?  Did you receive any errors at all during the upgrade?  I don't think you are required to re-authorize your geodatabase simply because of an upgrade from a technical standpoint; but my guess is that you are doing so from a legal standpoint in order to not use your client's license code.  This blog discusses the general process for re-authorizing a 10.1 geodatabase: http://blogs.esri.com/esri/supportcenter/2013/06/04/updating-the-license-for-enterprise-geodatabases-at-10-1/ I'm also curious to know what the VERSION table in ArcSDE contains. Another option is to run the Post Installation for ArcSDE, select custom, and select only the option to authorize the geodatabase. ... View more

The "Is Replica" flag is set to True in your most recent set of screenshots.  Is the dbo.DEFAULT version of the Communities_Points database set up for two-way replication or one-way replication where it is the child?  What is listed when you run the following query against your databases? select * from Communities_Points.DBO.versions I'm particularly looking to know if there are any SYNC_SEND_XXX versions which have not been synchronized.  You may want to query the GDB_REPLICALOG table as well to see if there are any errors reported in synchronization. ... View more

Hi, I'm new to GIS and I am having a problem with getting my point feature class to display the data points on the map.  I have a point feature class with an attribute table that contains UTM coordinate columns.  How do I get each point to display on the map? Thanks Brian Please provide the exact version of the ArcGIS Desktop software you are using (e.g., 9.3.1, 10.0 SP1, 10.2.1).  You indicate that you have a point feature class with "UTM coordinate columns"... so are you saying that you have a feature class projected in a UTM coordinate system or are you saying that you have a table which has two columns containing X and Y coordinate values?  What I'm really getting at here is to identify whether or not your table has a spatial column (usually called SHAPE) or not.  If what you have is actually a feature class, then there shouldn't be an issue when viewing it in ArcMap.  Are you getting an error or are no points showing up?  Are you sure there are records in the table to begin with?  If what you have is a table with X and Y columns containing values, then you need to utilize the Add XY Event Layer tool.  If you are looking at the "feature class" that you have in ArcCatalog, are you able to preview the spatial contents in the Preview tab or is there only an option to view its attributes in table format? ... View more

If you're using a 10.1 desktop client, you have the option to use the Create Database View GP tool as described here.  That being said, to generate spatial views with this tool you would need to be using ST_Geometry or Geometry rather than a binary storage data type.  So, if you're using SDEBINARY for example, this tool probably won't help you create spatial views.  I've always had good luck with the SDE command-line tools.  Although more complex commands can be tedious to write at times, the tools (at least the SDETABLE command tool) works with most if not all spatial data types.  There are times where I'll create the query using SDE commands and then further edit the view's SQL using RDBMS tools (e.g., SQL Studio Management Studio) afterwards.  I believe the SDE command-line tools are going away once the next release of ArcGIS comes out (whatever comes out after the 10.2.1 release).  The method you described for creating a query layer isn't the same as a what we'd traditionally call a "spatial view", which are persistent views that live inside the database and contain a spatial column.  In my experience, query layers are temporary views (which can be spatial or non-spatial) and reside only within a map document or model.  So in summary, you can use the Create Database View GP tool if you are using the right spatial data types.  Otherwise, use the SDE command-line tools as you are currently doing. ... View more

In the past with most ArcGIS for Server Upgrades you needed to completely uninstall the previous versions, loosing all your services and customizations. Then, starting from scratch, install the new version and have to spend hours and hours re-do all your services and customizations. I hope ESRI has finally created a way where upgrades simply overwrite previous versions leaving everything done previously intact. When upgrading from ArcGIS for Server 10.1.1 to 10.2.1 will I need to uninstall 10.1.1? Will I have to re-add services to Manager? I have some services that use Caching, will I need to re-do the Map Caching Scales? I use ArcSDE/SQL Server Express 2008 R2 for Geodatabases, is there anything that will negatively impact these if I upgrade? something I should know beforehand? Where can I find some good info on upgrading ArcGIS for Server 10.1.1 to 10.2.1? Upgrade paths for the Esri stack should proceed in the following order for the major components: Server first, clients second, geodatabase third.  Beginning at 10.2, you'll be able to install newer versions of the software on top of the existing 10.2 installation.  In the case you are describing, you won't be able to install 10.2.1 on top of 10.1.1; instead, you will need to uninstall 10.1.1 first.  Whatever customizations you have made will need to be installed/configured again unfortunately.  For the services, you might be able to open your service definition (SD) files after 10.2.1 is installed and re-save them as 10.2.1 SD files, but the downside is that you will still need to re-create your services and all of their parameters.  In the past, whenever I've had to replace a server, I've been able to simply copy the service configuration files from one machine to another but in that case I was using the same version of ArcGIS on the new machine.  In your case, you are keeping the same machine and changing versions entirely so I don't know how well it would go to try and re-use your 10.1.1 service configuration files with 10.2.1.  Your caches might be ok to stay intact; make a backup of the cache directories and files and copy them back to the same location once the installation is complete.  You'll just need to set your cached services to Cached and point them at the tiles when you re-create the services.  Try that first; if it doesn't work then you'll have to re-cache.  Your map documents (the things you used to create your SDs) for your map services can be re-used though; just open and re-save them in 10.2.1 first as I think that is best practice.  The geodatabase will not need an upgrade and neither will your ArcSDE command line tools; but if you do decide to upgrade those then upgrade your geodatabase last though, so that any older clients can still connect to the geodatabase as long as possible.  Newer geodatabases won't generally allow older clients to connect but Esri has a matrix they publish which shows connectivity compatibility between GDB and client.  Just remember to re-register your geodatabase as a data store with your new 10.2.1 installation of ArcGIS for Server. EDIT: Apparently for ArcGIS Server, Esri states that an "in-place migration is more feasible when moving from 10.1 to 10.2.1 because you are not required to uninstall 10.1. However, the migrated site should still be thoroughly tested before being exposed to end users".  So, it might be ok after all to perform the 10.2.1 installation on top of your 10.1.1 installation; however from my experience I wouldn't recommend doing that.  I've had much better luck uninstalling and re-installing Esri software than performing upgrades.  It's more work, sure, but it saves more headaches and 2-hour phone calls with Tech Support, in my opinion.  In any event, below is the upgrade documentation from Esri (I'm assuming you have a Windows environment for AGS): http://resources.arcgis.com/en/help/main/10.2/index.html#//0154000002p0000000 ... View more

Disregard some of my comments above.  It had nothing to do with the DB_NAME or the esri license.  I can connect to either standby if I perform a Switchover within OEM such that the primary and standby databases swap roles.  It has something to do with the read-only status of the database whereby Data Guard is enabled. ... View more

Please provide the version of Esri products with which you are working.  It will be easier for everyone to help you if you provide some basic details about your environment.  For your geodatabase, are you using a file geodatabase or an ArcSDE-based geodatabase.  If you are using ArcSDE, what is the exact version of the underlying RDBMS are you using?  If a file geodatabase, this thread might be better served in ArcGIS Desktop - General. ... View more

Upfront Comments: Please provide the exact versions of Esri and RDBMS products you are using.  We have a primary SDE that all general users and all web services access to use GIS data.  Then we have an editing SDE where GIS editors modify the data.  That data is then synced to the primary SDe nightly. Questions: How is the data being synced?  Which specific Esri GP tools are you using with Python and FME?    Currently the primary SDE is entirely unversioned, however now we want to host a dataset with a geometric network.  To update this dataset the primary SDE will need to have versions(we'd probably just edit default directly) and once the sync is complete we'd need to a compress. Comment: You are correct in that you would need to version your primary to receive replicated changes from your editing GDB.  This is the case whether you include a geometric network as part of the replica definition or not.  I will caution you, though, that depending on the version of ArcGIS you are using you will experience a long wait during synchronization for your geometric network to rebuild on the child replica (i.e., your primary).  The network rebuild logic is not very efficient for client-side rebuilds during replication synchronization.  If you must use replication, just be prepared for this.  Question: Are you only considering using versioning because you have a geometric network that you wish to exist in the primary?  I'm trying to understand the technical reason for why you are thinking about introducing replication.  However its my understanding that if there is a lock on states in an SDE then the compress will ignore the lineage for the state that's being viewed.  So I'm not sure we'd get an effective compress if lots of users and web maps are looking at DEFAULT.  I'd like to avoid kicking everyone off the server if I can, even if its at night since the web services are accessed external to our organization.  There really isnt any other editing on the server... only nightly python/FME data pushes through non-versioned operations. Comment: Compression is a common workflow for anyone with a versioned geodatabase.  You will not ever achieve a full compress (to state 0) if there are connections which put locks on particular states as you elude to.  However, compressing regularly will help to keep your lineage trimmed.  That being said, I think synchronizing from an enterprise GDB parent to an enterprise GDB child replica would put the edits into the delta tables on the child rather than make those edits directly to base.  You'll have to read through the Esri documentation to know this for sure, unless others comment on this thread who know the answer to that.  If the edits are put into the A and D tables, you'd need to compress the child replica too.  To actually move the edits from the deltas to the base tables, I think you would need everyone to disconnect in order to get to state 0 to do this.  That includes GIS services which access your GIS data from the primary. ... View more

In getting back to the original topic at hand, I found the following thread which discusses ArcSDE and Oracle Active Data Guard in a bit more detail:  http://forums.arcgis.com/threads/20100-Moving-an-SDE-Replication-DB-to-a-new-machine  In my particular case, I think the issues I am having are related to creating the standby database on the same machine as the primary.  Since this is a test environment, I did not think it would be a show stopper.  Of course, in a production environment we would have the standby on a separate machine.  Having the standby on a separate machine would allow the DB_NAME to match that of the primary database, which is something I am not able to do by nature of having the primary and standby on the same machine.  I think that might be why I am unable to connect to the standby right after creating it; the license for the geodatabase may need to be specific to the DB_NAME.  Hence, a different DB_NAME with the same license may not work.  The only thing I can't explain is why I still couldn't connect to the standby via ArcCatalog even after breaking replication, putting the standby in read-write mode, and successfully authorizing it with the Post Installation.  Moreover, I have not had to re-authorize test databases when importing dump files from a production export.  I could be wrong in my thought process here, but I'm just sharing what has occurred to me in the last few minutes.  I'll explore this a bit more and provide more results once I can get a second test server stood up for the standby database. ... View more

We are in the process of investigating this setup at my company - I don't have any answers just yet. Some of my concerns are what to do about the keyset_* tables and the sde log pool tables when a user selects more that 100 features. The keyset tables can be dropped periodically.  I think the best bet is to drop them up using a batch file that executes as a scheduled task.  As far as the log tables, I think you are referring to the SDE_LOGFILES and SDE_LOGFILE_DATA tables.  Yes, those get generated when the user selects 1,000 or more records from an ArcGIS client.  We convert them to Global Temporary Tables, which truncate automatically when the user logs out of his or her session.  On the next login, their selection set of 1,000 or more will utilize the global temp tables instead of generate a regular set of tables.   I've attached scripts to help you with these topics.  The keyset script will perform the drop of any keyset table.  The logfile script will generate the SQL to drop the logfile tables and re-create them as global temp tables. ... View more

Data loaded from other sources is typically via the copy/paste tools. The statement above makes me wonder if there are occasions where data is loaded from other sources without using a copy/paste operation.  In other words, I am wondering if there are rare occasions where data is atypically loaded.  If there are any other ways in which you load data besides copy/paste, please elaborate on what those are.  We have seen similar behavior in the past, and we narrowed it down to a CAD converter tool that we use to load data into our edit versions.  To date, we have not truly resolved the issue although it does not happen often. ... View more

�?� The only reason I replicate the enterprise geodatabase to file geodatabase is the performance. I gain some considerable speed in case my web mapping application reads from the gdb but not from mdf. �?� It is much efficient to replicate the enterprise geodatabase to file geodatabase rather than copying the enterprise to file. In case of light changes on the enterprise, these changes can be easily reflected to the file geodatabase by synchronizing them without the need to copy the ENTIRE geodatabase to file geodatabase �?� The 1000 records deletion limitation is an issue that I expect to be solved by ESRI. Regarding your first bullet, I would say that exporting or copying the data as I suggested still results in a file geodatabase.  You don't need replication to use or produce a FGDB.  Thus, you're not gaining anything by using replication for this reason alone.  Regarding your second bullet, I agree with you that it is more efficient to export and apply changes to a replica rather than re-produce the entire geodatabase to a FGDB.  I basically stated this in my last post.  That being said, as a workaround you have already stated that you need to re-create the entire replica anyways so this really should not matter.  Furthermore from my experience, replication comes with plenty of buggy behavior and a number of hard requirements that you would not otherwise have with exporting your data to a file geodatabase using Export or Copy.  If you have any geometric networks that you are replicating, you will see huge wait times before the network is completely rebuilt on the child replica... especially with re-creating the entire replica as you are doing.  You wouldnt see this with a copy or export.  If this is not an issue for you or if you don't have geometric networks that you're working with, then it's probably not a big deal as long as you're willing to muddle through the rest of the challenges with Esri replication.  Hopefully you've had better luck than me.  Regarding your third bullet, I wouldn't hold your breath about getting this fixed especially since it was reported at a recent release of 10.2.  Even if there is a documented NIM, it could be months before it's fixed. ... View more

If you are deleting and replacing the replica geodatabase entirely as a workaround, why not just consider a different approach to achieve your goal?  Depending on your workflow and requirements, you may not even need to use replication.  Would it be feasible for you to simply generate an export of the data you need at a specific interval?  Instead of performing a synchronization only to find out that it doesn't work if there are 1,000 or more deletes, you might save yourself more time to just use the export or copy GP tools to produce the output file geodatabase altogether.  Then you could delete the output prior to re-exporting your data each time.  One of the reasons for using one-way replication is to avoid having to re-generate the entire geodatabase when changes are made; hence it allows you to simply export the deltas and apply them to the replica.  If you are finding that you need to re-generate the entire replica each time, it seems self-defeating to use replication.  If you must use replication based on your requirements, you could consider synchronizing twice instead of once so that you don't run into the 1,000-record deletion issue.  For example, sync once after 500 deletes and then again after 500 more deletes. ... View more