|
POST
|
The ArcSDE API actually hides the fact that SDELOB (and SDEBINARY, though one shouldn't be using LONG RAW so long after it was deprecated by Oracle) uses a joined table, by aliasing the joined Fn table with the geometry column name, so that the API equivalent of SELECT shape.numofpts,shape.area,shape.length FROM tablename returns the expected values. You can emulate this in SQL by using the same trick: SELECT shape.numofpts,shape.area,shape.len length FROM tablename a, Fn shape WHERE shape.fid = a.shape or SELECT shape.numofpts,shape.area,shape.len length FROM tablename a JOIN Fn shape on Fn.fid = a.shape For most uses, SDE.ST_GEOMETRY will be a better storage choice than SDELOB, and this gives you access to a larger set a accessor functions and operators. - V
... View more
10-15-2015
01:51 PM
|
1
|
0
|
1840
|
|
POST
|
When you're working with services you need to think asynchronously. You can't control processing order or prevent jobs from being issued at the same time, so a unique job assignment mechanism should be used (UUIDs are great for this purpose). I don't generally consider processing failure to be a real threat, but I do have to consider the possibility that the server will be shut down before processing completes, and architect a solution that permits an "ACK/NACK" to be sent to the controller with ternary logic (success, retry, failure). If extraction time is a significant cost, you'll need to come up with a mechanism to persist the extracted data until a successful processing job is completed. Many servlet frameworks have built-in capabilities to manage, persist, and retry jobs; you should review the options for your environment before deciding to create your own queue management solution. But the extracted data should not be placed in the scratchGDB that is managed by ArcGIS Server. - V
... View more
10-13-2015
09:21 AM
|
1
|
1
|
1719
|
|
POST
|
Do not attempt to use the ScratchGDB assigned to a different service in a later service -- This can cause the tables in the scratch folder to disappear before you need them, or locks on the folder to cause background deletion to fail. The end result for a service should be data in a "safe" location (I've created my own "JobFolder" object to manage this externally), usually passed into the service as a parameter. If you have two cascading services, you can merge them if it makes sense, architecturally. Generally smaller, self-contained services will make better building blocks than large complex services. - V
... View more
10-12-2015
08:37 PM
|
1
|
4
|
1719
|
|
POST
|
You'll need to provide exact details of the version of ArcGIS, the database product, the database product version, the geodatabase version (if not the same as ArcGIS), the exact SQL you are using, and the coordinate values associated with at least one feature. You'll also need to provide how you determined that the radius was sub-meter in WGS84. - V
... View more
10-09-2015
07:28 PM
|
0
|
0
|
2772
|
|
POST
|
Best practice-wise, if you're replacing the contents of a table, you should be doing so as the owner. Only the owner has the ability to: Truncate a table, Place it in load-only I/O mode, Quickly load the table, then Toggle normal I/O mode, rebuild the indexes, and update the statistics. Even if you accomplish the TRUNCATE without being the owner, all the others are REQUIRED for adequate performance; you're setting yourself up for a 7-ball juggling contest while placing one arm in a sling and belting yourself to a unicycle. II don't understand your description of the data flow, but if features are allocated in sequential order, it's likely because the free list was empty or exhausted by bulk insertion. - V
... View more
09-30-2015
10:34 AM
|
0
|
1
|
2632
|
|
POST
|
In database terms, DELETE is something that happens to rows. Table deletion is referred to with the directive DROP. If you did DROP the table it wouldn't be an issue, since TRUNCATE is a lot like dropping the table then recreating it, without the mess of having to repopulate the database catalog and recreate all the indexes. I did state that rows inserted into blocks allocated to a table's free list would produce random ordering. I didn't go into it the why, but there's an entire domain of Computer Science to choose how to most efficiently reallocate an existing list of storage, and the algorithms most likely to make most efficient use of the space are also least likely to result in features physically stored in insertion order. You should use the Truncate Table tool I referred to in my answer, instead of Delete Features, but if you aren't replacing contents as the table owner, then you'll need to research the proper way to construct a stored procedure to permit that to happen (it's similar, but different in Oracle and SQL-Server). Depending on the geometry storage model, you may need to manually TRUNCATE ancillary tables as well. - V
... View more
09-29-2015
06:17 PM
|
0
|
3
|
2632
|
|
POST
|
Once you start using DELETE, the database is well within rights to place rows in any page it deems appropriate (each table has its own "high water mark" of previously allocated extents). If you actually TRUNCATE the table instead of DELETE, then the rows would likely be placed in the order you inserted them (since the high water mark is cleared, and new blocks are being allocated) It's important to know that the database is not obligated to return rows in any particular order unless an ORDER BY clause is used. Also, once the spatial extent reaches a quarter of the overall extent, spatial queries are likely to return features in spatial index order. - V
... View more
09-29-2015
01:47 PM
|
0
|
5
|
2632
|
|
POST
|
Installing the application server software isn't enough -- The configuration files must have correct values. The error indicates that ORACLE_SID or TWO_TASK variable in dbinit.sde isn't set correctly, or that the client can't connect to the server for some reason. You really ought to contact Tech Support, because ironing out this sort of issue usually requires a great deal of back-and-forth. - V
... View more
09-25-2015
09:20 AM
|
1
|
0
|
2094
|
|
POST
|
It's not important to keep the server name similar, but it is critical to keep the database name(s) the same. There are a number of ways to get a backup installed on the new server, but the one I've used is: Detach the database Copy the datafiles to the new server Reattach the datafiles to the old server (old server is now live) Attach the datafiles to a database with the same name on the new server Use sp_change_users_login to repair the login ids for the new database Upgrade the database (if going from 2008 to 2012) Upgrade the geodatabase (if changing ArcGIS versions) Test, test, test until you're sure everything is fine Let trailblazers start working on the new server When ready, shutdown the old server (or reboot with a new IP) and reboot the new one with a changed IP address. You can even go several passes at this process, until you feel comfortable leaving the old server offline. - V
... View more
09-23-2015
06:08 PM
|
4
|
3
|
8474
|
|
POST
|
That's difficult, because there aren't any good naming conventions that merge source name and field with an underscore in ten characters. It's all part of why shapefiles should be avoided (naming limits, lack of wide strings, BLOBs, CLOBs, and numeric nulls, limited date representation, 2Gb file limit...) - V
... View more
09-23-2015
02:19 PM
|
2
|
0
|
1878
|
|
POST
|
That's your problem right there. Shapefiles have limits on field name width, which are generally dealt with by making aliases in metadata and naming the columns to sequential names that don't conflict. Do your analysis in FGDB then rename the columns on export to shapefile when you're done. - V
... View more
09-23-2015
01:24 PM
|
2
|
2
|
1878
|
|
POST
|
Keep in mind that there isn't a SQL database backing an in_memory workspace. I wouldn't expect any complex SQL statements to work, and I'd be leery of trying to use even basic functions (like length). File geodatabase attempts to emulate some of the SQL language, but shapefiles and in_memory feature classes don't have more than simple WHERE expression operators. - V
... View more
09-23-2015
12:33 PM
|
1
|
5
|
2930
|
|
POST
|
If you use ArcGIS to delete a view, it will drop the view. Only the view. - V
... View more
09-03-2015
05:50 AM
|
0
|
0
|
4242
|
|
POST
|
It isn't possible to "unregister" a view. The only way to clear GDB metadata is to delete the object using Desktop (so some other geodatabase-aware tool, like a Python script). As you have seen, modifying the tables using SQL cannot update geodatabase metadata. - V
... View more
09-02-2015
07:30 PM
|
1
|
2
|
4242
|
|
POST
|
No, there is no requirement that data be stored in sde.ST_GEOMETRY to be published as a feature service. In order to publish a feature service, the source feature class must be registered with the geodatabase. This means an enterprise geodatabase must be installed. But there is no reason why you cannot register a feature class using SDO_GEOMETRY geometry storage. I do not recommend using Create Spatial Type unless you have no intention of enabling the database instance as an enterprise geodatabase. - V
... View more
09-02-2015
07:20 PM
|
1
|
0
|
1799
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 06-30-2026 09:35 AM | |
| 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 |