|
POST
|
While it may not be impossible, reconstituting this data will require more information than you currently have (and probably several weeks of work). If you need to go back to the provider anyway, it's probably easiest to ask that they provide the data in a specific format (file geodatabase, ArcSDE shpexport, shapefile, XML, even ASCII). Make sure you talk to the GIS people, not a database admin who is clueless about spatial data formats. - V
... View more
05-02-2012
03:47 AM
|
0
|
0
|
911
|
|
POST
|
That's more of a language issue than anything else. I'd be afraid to access an iterated object outside its valid scope. - V
... View more
05-01-2012
06:30 PM
|
0
|
0
|
840
|
|
POST
|
The file geodatabase API only works with ArcGIS 10.x file geodatabases. I doubt the files you are trying to load are 10.x, but you'll need to check with the data provider. - V
... View more
05-01-2012
06:23 PM
|
0
|
0
|
740
|
|
POST
|
Yes, secondary queries do probably take a different path through the SQL engine, but if the registered rowid was unique (as it is required to be), it wouldn't matter. Some folks try to game the unique requirement by returning row number in the view rowid column, but since the value is used to refetch the row, this will result in random results without the previous WHERE constraint (and that's before you consider caching and other optimizer tricks that could reorder the return sequence). Since you do have an OBJECTID in LR_Stakeholders, you should use that in the create_view column list (vice the 'many' one). I've done this extensively with GeoNames data that actually has distinct places and names (alternate spellings for the same location); so long as you fetch the rowid from the many table, ArcGIS won't notice that one-to-many isn't supported. - V
... View more
05-01-2012
06:29 AM
|
0
|
0
|
1477
|
|
POST
|
Actually, this is the expected result -- chaos! One-to-many views are not supported by ArcGIS because it *must* have a unique registered rowid column (objectid) to tie the table to the geometry. This view would be supported if you had a unique NOT NULL integer column in the stakholders' table, and specified *that* in lieu of the non-unique OBJECTID (note a rownum is not permitted, because the value must be reproducible in subset queries). Relationship classes are the geodatabase methodology to provide full support for "many" relationships in ArcGIS. - V
... View more
05-01-2012
03:41 AM
|
0
|
0
|
1477
|
|
POST
|
No, you've got it flipped backwards. Enterprise ArcSDE will operate on SQL-Server Enterprise, Standard, or Express databases, but Workgroup ArcSDE will only work with Express (more specifically, with the *specific* release of Express with which it ships -- no substitutions). - V
... View more
05-01-2012
03:02 AM
|
0
|
0
|
2466
|
|
POST
|
There's some fundamental issues here, and I don't see any way through them without doing some basic review: Microsoft SQL-Server is a database. Management Studio is an administrative client to SQL-Server. Microsoft publishes a library so that other clients can connect to the database server as well. At no time will any other client, like ArcGIS or ArcSDE, connect to Management Studio. Management Studio is used to configure the database, so that users exist for clients to connect, but it has no role in the clients' connections to the database server, and it is not possible to use it without a database server. There are a number of different versions of SQL-Server. Microsoft has chosen to split the capability of their core software into "Enterprise", "Standard", and "Express" classes. They also have the "old" release (2008) and the "new" release (2012). While you can chose the database you want to use, you can't control the ability of older software clients to work seamlessly with newer servers (sometimes the new servers will permit old clients, but it's rare that there's any way for the old client to access new capabilities). It would be unwise to assume that you could use 2012 Express with ArcGIS 10. ArcSDE is a "middleware" component -- it acts as a server to clients at the same time it acts as a client to a database server. The technology of the ArcSDE middleware has also been configured into a DLL which can run inside a client, which allows a client to be it's own server, and talk directly to the database (this is called Direct Connect). Esri also exploited opportunity presented by the existance of SQL-Server Express to provide "Personal ArcSDE" and "Workgroup ArcSDE" products. These technologies are closely coupled to ArcGIS, and don't really have much to do with the capabilites of Enterprise ArcSDE -- the connection protocols are different, as are the administrative tools. ArcGIS 10 also added a capability for clients to connect to spatially-enabled databases directly, without using ArcSDE (aka "Query Layers"). It is not, however, possible to mix-n-match the protocols so that you can use a 2008 Express-specific client to talk to a newer release of the database with an ArcSDE query layer. I suggest you choose one technology, and explore its capabilities and limitations before trying to integrate any other similar technology into your environment. If you work chronologically, you'll have less trouble (and by the time you reach it, the newest ArcGIS may be able to talk with the newest Express). - V
... View more
04-30-2012
01:09 PM
|
0
|
0
|
6234
|
|
POST
|
The order_by clause is a separate component in the ArcSDE SE_QUERY_INFO object used to query the stream. I haven't looked to see if it's available from ArcObjects, but it's unlikely to be available though the where clause in that tool. You might be able to use an ORDER BY in a subquery, but there's still no guarantee that a query (especially a spatial query) would honor the subquery order. It is very likely that the resulting query would be much slower. Even if the export order is reliable, there's still no guarantee that the objectid insert order will always be increasing (generally, it is, but it's not requred), so you could still have subtle errors in alignment. I suggest you use a column other than the registered rowid column for this purpose. You'll most probably need to code your own export tool to achieve this goal. - V
... View more
04-30-2012
09:28 AM
|
0
|
0
|
1121
|
|
POST
|
I would recommend the Understanding Coordinate Management in the Geodatabase whitepaper for the details, but simply put, *every* layer in ArcSDE has a coordinate reference, which encompasses the coordinate system, the precision, the false offsets and scales for the X/Y, Z, and M dimensions, and the tolerances for those dimensions. The default offset and scale for the Z dimension are 0 and 1 (respectively), meaning you could not capture data below sea level and only at 1 unit intervals. Therefore, you need to define a Z component on the coordref any time you intend to store coordinates with a Z dimension (that is, a Z value with *each* coordinate, not a single "ELEV" attribute property for the feature). - V
... View more
04-28-2012
08:53 AM
|
0
|
0
|
985
|
|
POST
|
The only way to be certain of a consistent order is to apply an ORDER BY on the query. It's probably not particularly safe to rely on the objectid for this purpose. - V
... View more
04-28-2012
08:42 AM
|
0
|
0
|
1121
|
|
POST
|
Not wrong. Just simplistic. I strongly discourage the use of 'sdetable -o create_view' for anything but creation of spatial views on SDEBINARY storage layers. The best way to work with native geometry is in SQL (e.g., CREATE VIEW xxx AS SELECT ...), at which point 'sdelayer -o register' is used to make the result available to ArcSDE. The main problem with simplistic examples is that the complixities of real world data reduce their value -- in this case, trying to work both methods into one example confuses the issue on when you should use each method. - V
... View more
04-27-2012
05:46 AM
|
0
|
0
|
1053
|
|
POST
|
The whole purpose of using 'sdetable -o create_view' to to preserve the layer information so that an additional 'sdelayer' isn't necessary. Make no mistake -- ArcSDE doesn't have any knowledge of "feature classes" or other geodatabase entities, but ArcObjects does, and it presents the "new" "table" as a simple feature class. Views cannot be versioned, and therefore cannot participate in feature datasets. - V
... View more
04-27-2012
03:52 AM
|
0
|
0
|
1053
|
|
POST
|
The information remains in the database; they're just stored as CLOB text strings in the few remaining sde.GDB_* tables. The denormalized form makes opening a geodatabase significantly faster, but by being more computer-ready, they're less human-readable (and *much* less human-writable). It's been a while since 10.0 was released, but these changes were discussed at great length when they happened, and the documentation has been updated to reflect the new architecture. I encourage you to delve into the "What's New at 10.0" documents to familiarize yourself with the other changes. - V
... View more
04-27-2012
03:39 AM
|
0
|
0
|
935
|
|
POST
|
Everything is stored as XML at ArcGIS 10. Teasing it out with SQL wouldn't be easy. - V
... View more
04-26-2012
05:52 PM
|
0
|
0
|
935
|
|
POST
|
No, no! You *don't* want 'sde' in the Administrator or DBO groups, else SQL-Server will promote your 'sde' to DBO. - V
... View more
04-26-2012
07:24 AM
|
0
|
0
|
4422
|
| 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 |