|
POST
|
If your environment is that ancient, you should at least consider a fresh install and full data migration. This would allow you to review the data schema and application architecture, and upgrade what is necessary. It would also permit spatial defragmentation and coordinate reference optimization, which could significantly improve performance. Finally, you would have multiple opportunities to get the data transition correct (a true proof of concept) before migrating the applications. - V PS: Please specify the database; since "SDE" no longer exists, the term of art is "enterprise geodatabase" or "<Name of DBMS> enterprise geodatabase".
... View more
05-03-2017
07:52 AM
|
3
|
2
|
3096
|
|
POST
|
Python is one of very few languages where the modulus operator works on floating-point datatypes. Usually a math function (e.g., fmod) is required, with the operator only supporting integer types. I tested in Python 2.7 (which is why I got away with the paren-less print).
... View more
04-27-2017
07:28 PM
|
2
|
0
|
3971
|
|
POST
|
The Python modulus operator (%) can be used to force a range on even floating-point values: >>> print (358.1 + 4) % 360.0
2.1
>>> print (3.0 - 12) % 360.0
351.0
... View more
04-27-2017
02:50 PM
|
1
|
2
|
3971
|
|
POST
|
Have you tried a non-Esri forum (more specifically, a Microsoft one) to obtain this answer? Even a vendor-neutral site like GIS StackExchange is more likely to have this answered than here in GeoNet. The PostGIS operator is ST_DWithin, but neither SDE.ST_Geometry nor the native Microsoft geometry/geography operators support that method, so you'd need to evaluate using an ST_Buffer with ST_Intersects (which uses a spatial index, if available) and ST_Distance (which doesn't use a spatial index at all). I need to point out that SQL Server 2008 is very old software (released in beta nearly a decade ago), and support for it among GIS vendors (and Microsoft) is waning. You should consider upgrading to at least SQL Server 2012 or 2014, which were at least released this decade. - V
... View more
04-24-2017
11:56 AM
|
1
|
0
|
2486
|
|
POST
|
[This got detached from the thread stream by auto-save; pasted back in where it belongs] Rex gave you two SQL statements, though the second one has a typo ('Updated features' instead of 'Deleted features'). Working with the two of them you should be able to synthesize the distinctions between inserts and updates, and deletes and updates. - V
... View more
04-20-2017
06:56 AM
|
0
|
0
|
5067
|
|
POST
|
Correct. Individual edits associated with a state only exist in the An and Dn tables associated with each table. To find all edits associated with all tables participating in that state would require iterating all versioned tables. - V
... View more
04-20-2017
06:53 AM
|
1
|
0
|
5067
|
|
POST
|
Any SQL query solution can be implemented in ArcPy through an arcpy.ArcSDESQLExecute cursor.
... View more
04-17-2017
06:56 AM
|
3
|
2
|
5067
|
|
POST
|
You'll probably want to detail your issues with 10.0->10.4 migration as a different question in a different group. I had no significant problems porting some pretty complex ArcObjects Java SOEs from 10.0 to 10.1, then adding complexity and porting to 10.2, then 10.3, then 10.4, so you may be just dealing some of the fundamental changes that occurred at the 10.0-10.1 migration. - V
... View more
03-29-2017
10:09 AM
|
1
|
0
|
2411
|
|
POST
|
Note that you might have issues working with large selection sets which use logfile tables in the database. "Read-only" users are granted CREATE TABLE to support logfile creation.
... View more
03-28-2017
09:04 AM
|
1
|
1
|
2906
|
|
POST
|
1) No, a spatial view can only see what SQL can see, which is tables in the database 2) Not possible, but using network drives is a poor solution, even for situations where it is possible. 3) The only solution is to load the data into the database. Note that Excel is not a database format, and shouldn't be considered one; working with data coming out of Excel requires an awful lot of error handling. Real-time or near-real-time updates based on a flat file are extremely difficult to detect and manifest - a mediocre implementation could take weeks to stabilize, and a robust solution might involve months and custom modifications to the database itself. - V
... View more
03-28-2017
07:31 AM
|
1
|
0
|
1471
|
|
POST
|
ArcGIS 10.0 has been Retired for nearly 15 months. I'd be afraid to use the ancient Python that shipped with 10.0 for even non-ArcPy use. Attempting to use a modern ArcPy script with an ancient ArcGIS build isn't likely to be successful.
... View more
03-28-2017
06:36 AM
|
2
|
2
|
2411
|
|
POST
|
DeleteRows is not efficient (no "delete" is), but TruncateTable is, not that it would much matter with only 20k rows (but if you cross 500k rows, you'll notice a difference). - V
... View more
03-23-2017
06:42 AM
|
0
|
0
|
8447
|
|
POST
|
You seem to have forgotten to back up and restore the SDE user (between steps 5 and 6), and to upgrade the 10.1 schema tables to 10.4.1 between steps 6 and 7).
... View more
03-22-2017
09:47 AM
|
0
|
0
|
1488
|
|
POST
|
That is an exceptionally convoluted path to do what ArcPy can do in under a page of code (with a da.UpdateCursor, swapping ordinate order). I wouldn't recommend passing ANY GIS data through Excel, just on principle. - V
... View more
02-28-2017
06:25 AM
|
1
|
1
|
4150
|
|
POST
|
Be careful! A "shapefile" is a specific set of files with a published set of formats. It is not possible to create a shapefile "in" a file geodatabase. Creating a feature class in a file geodatabase creates a new table within the FGDB, which is allocated the next available "slot" in the file geodatabase naming scheme. When you import a shapefile into a file geodatabase, you are creating a new table with a similar schema, but the data is no longer in shapefile format. If you physically place the shapefile set member files in the ".gdb" parent folder, you will render these files invisible to Desktop or Server, because a ".gdb"-suffixed folder has a special meaning to the data discovery subroutines. The "system catalog" approach used in file geodatabases (to store the file names and column properties in tables of the geodatabase schema itself) is an old, old trick, that predates the "INFO" days of Arc/Info. It is also used by PostgreSQL; you can see this if you ever wander into a tablespace directory owned by the 'postgres' user. Oracle and SQL Server do the same, but the virtual tables are hidden in the black-box implementation of "tablespaces" and "filegroups". In order to archive a file geodatabase you must capture ALL of the files under the ".gdb" directory (including the directory itself, but with the possible exception of the ".lock" files). Creating a new table will create new files and modify others. Adding rows to a table will modify the data file and any index files. You can guess which "slot" is issued to which table by the growth pattern, but it is not in any way "safe" to archive only the data files in the slot without the framework that supports the content. I should probably also mention that file geodatabase is recommended for local, not network-shared, use. Something about the perfectly reasonable file access pattern used in the ArcObjects and FIle Geodatabase API makes for a significant (~2x) I/O performance penalty over a network. - V
... View more
02-03-2017
09:11 AM
|
2
|
1
|
2292
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 3 weeks ago | |
| 2 | 06-08-2026 09:13 PM | |
| 1 | 05-29-2026 12:51 PM | |
| 1 | 06-01-2026 06:03 PM | |
| 2 | 05-29-2026 08:31 AM |