|
POST
|
The OGC intent was certainly to permit subqueries, but there's still the SRID issue with which to contend. A Microsoft forum would probably be a better place to find experts on GEOMETRY behavior in SQL-Server 2008. ArcSDE just uses an envelope search as a filter and then uses Esri's libraries for topological comparison (whether it's GEOMETRY/GEOGRAPHY, ST_GEOMETRY, SDO_GEOMETRY, PG_GEOMETRY , SDEBINARY, or SDELOB storage). Shape library comparisons are done at the precision specified by the layer coordinate reference (inverse of xyscale). - V
... View more
04-06-2011
04:13 AM
|
0
|
0
|
737
|
|
POST
|
That behavior is by design, to reduce clutter. The other schema's tables might just be feature datasets (owned by other users, but not accessible because one or more of the tables within are not SELECTable). - V
... View more
04-06-2011
03:12 AM
|
0
|
0
|
293
|
|
POST
|
The ArcSDE 'C' and Java SDKs are on separate media, which can be ordered through Customer Service. - V
... View more
04-05-2011
11:27 AM
|
0
|
0
|
530
|
|
POST
|
What platform are you using? Which version and service pack of ArcSDE are you using? Do you have the Java ArcSDE SDK installed on the client? - V
... View more
04-05-2011
07:33 AM
|
0
|
0
|
530
|
|
POST
|
Tweak and prod at will. Just keep in mind that bitmasks are the most likely means of implementing subtle changes in behavior between releases, and are therefore least likely to be reverse-engineered safely. Read-only is the safest use of a bitmask, but is still not without risk (mostly errors of omission). There are three ways to access spatial data through ArcGIS: + Via ArcObjects + Via the ArcSDE API + Via SQL ArcObjects uses ArcSDE uses SQL, so the safest way to manipulate database objects registered with ArcGIS is AO. Simple feature classes which are only registered with ArcSDE are safe to manipulated with ArcSDE, and databse objects which have not been registered with ArcSDE are safe to be manipulated with SQL. Nothing in the ArcSDE data model addresses constraints, but ALLOWS NULL/NOT NULL is a fundamental column property. Both the ArcSDE API and the 'sdetable' command allow alteration of the allows_null property. If the table is registered with ArcGIS I'd recommend using ArcGIS to make the change, otherwise 'sdetable -o alter_column -x ALLOW_NULLS -t ...' will make sure that ArcSDE sets the correct bitmask in the columns table. Altering tables through database interfaces is a common part of spatial database maintenance, though some alterations are riskier than others (especially with regard to versioned tables). Since, in the end, most of ArcSDE is implemented as SQL, most anything you break can be fixed again (just make sure you have a verified backup/ recovery procedure and a fresh snapshot before you venture into unsupported realms). It is also important to keep causality in mind -- changing the bitmask flag which indicates a column's 'allows_null' property does not change the target column's null behavoir in the database. This option should only be pursued if an 'sdetable -o describe' as the owner reflects different information than a DESCRIBE does (and it still might not alter ArcGIS's interpretation of the same column). The few times I've needed to hack the column registry, I usually wound up reloading the table anyway, making it a moot exercise. - V
... View more
04-05-2011
07:28 AM
|
1
|
0
|
1852
|
|
POST
|
The POLYGON constructor accepts an SRID, but the ArcSDE SRID and Microsoft SRID might be different values. You need to use the Microsoft SRID in the native OGC operators. The ArcSDE sequence-generated SRID is a link to a row in the spatial reference table, where the native SRID resides. - V
... View more
04-05-2011
04:34 AM
|
0
|
0
|
939
|
|
POST
|
Microsoft's documentation states: This method always returns null if the spatial reference IDs (SRIDs) of the geometry instances do not match. You didn't show the SRIDs involved, but that's the most likely cause. - V
... View more
04-05-2011
04:03 AM
|
0
|
0
|
939
|
|
POST
|
I doubt the bit masks in OBJECT_FLAGS are meant for public consumption. I know the meaning of the LAYERS flags have evolved over time, so you'd be setting yourself up for a nasty case of "I just upgraded and my app no longer works". - V
... View more
04-04-2011
01:08 PM
|
0
|
0
|
1852
|
|
POST
|
If you had been using the single database model, it probably would have been as simple as detach, copy, reattach (this isolation is one of the critical benefits of that model). The inability to rename databases becomes a key factor when trying to prepare for such transfers. - V
... View more
04-02-2011
05:32 PM
|
0
|
0
|
1129
|
|
POST
|
I've done some pretty exotic things to transfer large rasters in the past, including a months long copy job over a slow an unreliable network link, but none of them involved 'sdetable' for managing rasters. It may be theoretically possible to use database tools to transfer the raw binary data, but I've never been forced to try. Using modern hardware, I did a full-on copy of a terabyte of JPEG-compressed (15-25Tb transfer) in under 40 hours. For 200Gb, you may just be better of copying with a drag-and-drop approach. - V
... View more
04-01-2011
02:30 PM
|
0
|
0
|
1129
|
|
POST
|
You *really* don't want to rename databases -- Doing so corrupts all the fully-qualified database object references generated by ArcSDE (sde_* table metadata is just a trivial part of the problem). This is why renaming databases is unsupported by Esri. If you want to create new single-database model ArcSDE instance databases, you can name them appropriately, then copy the data from old to new. (UNSUPPORTED RISK="MediumHigh") In the past I've run both single and multi-database model ArcSDE instances in a single SQL-Server instance, but the only way I could get it to work was to shutdown the multi-database service, detach the 'sde' database, do my new instance management, then re-attach 'sde' and re-start its application server process. (/UNSUPPORTED) - V
... View more
04-01-2011
12:06 PM
|
0
|
0
|
1129
|
|
POST
|
The purpose of query layers is to view native geometry tables without installation of and registration with ArcSDE. I'm not even sure that you can change the default storage in Express databases (Personal and Workgroup don't have the same range of functionality as Enterprise ArcSDE), and if you didn't, then the SDEBINARY geometry storage would not be visible to the Query Layer interface as anything but an integer. It sounds like your install is working according to design. - V
... View more
04-01-2011
04:10 AM
|
0
|
0
|
503
|
|
POST
|
Using DELETE won't free the high-water storage for those tables. You can either TRUNCATE or DROP them (they'll get recreated in either the default tablespace or according to DBTUNE storage rules). - V
... View more
03-30-2011
06:41 PM
|
0
|
0
|
727
|
|
POST
|
The internal structure of those formats are proprietary, and will not be published. This is quite common with working formats that evolve with each release -- Once published, the originator loses flexibility to adapt to changing technology (which is one of the reasons that shapefiles are limited to 2Gb in the .shp component). Since the FileGBDAPI exposes attributes though getter/setter functions, and uses the shapefile geometry spec for vector transfer, you likely have enough to tick the ".gdb" checkbox. - V "The nice thing about standards is that there are so many of them to choose from." -- Andrew S. Tanenbaum
... View more
03-30-2011
04:01 AM
|
0
|
0
|
680
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | 10-10-2025 07:28 AM | |
| 2 | 10-07-2025 11:00 AM | |
| 1 | 08-13-2025 07:10 AM | |
| 1 | 07-17-2025 08:16 PM | |
| 1 | 07-13-2025 07:47 AM |