|
POST
|
You are using an elderly release of ArcSDE (9.3 sites should be at 9.3.1 SP2 by now), but I doubt this is the issue. The error is generated from the database, so looking in the database logs may be useful. - V
... View more
03-01-2012
12:39 PM
|
0
|
0
|
3459
|
|
POST
|
I wouldn't have thought it possible to remove the login of a user that owns data, but the disparity between logins, users, and schemas is probably what will save your data integrity. However, you'll need to pay close attention to the mapping of the "new sde" login's login-id to the user-id in the database (they will no longer match). The sp_change_users_login procedure is really designed to deal with the complications of attaching a database from a foreign instance, but you'll need to use it to reassociate the 'sde' login with the 'sde' user/schema. Good luck. - V
... View more
02-28-2012
07:10 AM
|
0
|
0
|
3276
|
|
POST
|
Esri only supports Solaris on SPARC architecture. That error message results from trying to read SPARC binary as a shell script on a non-SPARC OS. - V
... View more
02-27-2012
08:33 AM
|
0
|
0
|
721
|
|
POST
|
That's a generic error message that can be caused by many things (I've personally seen 8-10 different causes). You need to review the logs created in the SDEHOME\etc directory to figure out where to go next. Sometimes it helps to run 'sdemon -o start' to get the error message in realtime. - V
... View more
02-27-2012
07:43 AM
|
0
|
0
|
1425
|
|
POST
|
Yes, it's certainly possible, but a search on "custom ODBC driver" indicates it would likely be exceedingly difficult to write one from scratch, even for a team of seasoned C/C++ developers (and that doesn't even consider how you'd model the spatial component in an interface that doesn't contemplate spatial data). - V
... View more
02-27-2012
02:27 AM
|
0
|
0
|
2190
|
|
POST
|
There's zero chance of being given the ST_GEOMETRY source. Your best chance at getting alternate libraries is to file an incident with Tech Support, making a business case for supporting an unsupported environment (I expect it would have to be a very compelling argument, just to make it to technical evaluation). - V
... View more
02-24-2012
06:38 AM
|
0
|
0
|
2744
|
|
POST
|
Query Layers work with native geometry types, so the layers would have to use GEOMETRY or GEOGRAPHY storage to be accessible. - V
... View more
02-21-2012
09:51 AM
|
0
|
0
|
1128
|
|
POST
|
I *always* create my own SDE tablespace and SDE user before beginning post-installation. I also prefer to execute 'sdesetup' (and 'sdeservice') at the command line, but even the post-install allows you to skip tablespace and user creation. - V
... View more
02-21-2012
02:01 AM
|
0
|
0
|
2155
|
|
POST
|
When I look at the documentation, it says that snapshot databases are read-only -- ArcGIS requires read-write access for connections, locks, and selection sets. The doc doesn't say, but it seems likely that the snaphot will have a different name -- Changing the database name invalidates all the triggers, which prevents ArcSDE from functioning. Just on these, I'd have to conclude: No, it's not possible. - V
... View more
02-20-2012
01:55 PM
|
0
|
0
|
1128
|
|
POST
|
I really don't know which "should" be faster. I know the SDEBINARY format and how much compression to expect relative to a shapefile or ASCII representation for various sizes of shapes of differing types and coordinate reference parameters, but I'm not familiar with Microsoft's internal representation the way I am with SDO_GEOMETRY. This is why I recommended prototyping. There are enough differences between deployments that it's not really easy to predict how all the pieces will behave with different variables. - V
... View more
02-17-2012
08:10 AM
|
0
|
0
|
1927
|
|
POST
|
There's probably a lot of interrelated things going on here. AUTOEXTEND is a datafile property (tablespaces reside in one or more datafiles, and tables [or their partitions] are assigned to tablespaces). This would have an impact on not being to add rows (if the tablespace storage had been exhausted), but not on query, per se. There's probably dozens of things that can be done to improve query performance, but the order in which they should be attempted depends on the answers to these questions: + What geometry storage is being used (ST_GEOMETRY, SDO_GEOMETRY, SDELOB, SDEBINARY)? + Is your table versioned? + Have you used DBTUNE keywords to distribute the table(s) and LOBs across tablespaces? + How many rows in your business table? + If versioned, how many rows in your adds and deletes tables? + If versioned, when was the last time you did a compress? - V
... View more
02-16-2012
07:16 AM
|
0
|
0
|
763
|
|
POST
|
The SE_SHAPE object keeps the shape type, envelope (4-D), LLONG (or LONG, for BASIC) array, part array and SE_COORDREF. If you bind a shape to a query stream (or, less efficiently, use SE_stream_get_shape), then the SE_COORDREF is that of the shape in the table. If you use SE_shape_set_coordref on a shape, it *clobbers* the previous SE_COORDREF without changing the other variables, shifting the location in simple transform (generally speaking, you should not ever use set_coordref without first using make_nil). If you use SE_shape_change_coordref (either directly, of by using SE_stream_change_coordref), it will "project" (really just transform, when without a projection or coordsys change) the shape to retain coordinate values (as much as possible -- precision cannot be increased). Thus, a copy utility should SE_layer_get_coordref from the target, create source and target shapes, bind the source shape (without setting coordref), bind the target shape (ditto), fetch the row, call change_coordref to change to copy the source shape to the target coordref in the target shape, and execute the insert. Using the stream function would catch change_coordref errors as stream errors, so I prefer not to use it, but you could eliminate a shape and make the copy loop into { fetch, execute }, which has some allure. - V
... View more
02-13-2012
12:18 PM
|
0
|
0
|
364
|
|
POST
|
The details are all in the whitepaper, but all Esri-formatted geometries are stored internally in an integer format. The long (or long long, for HIGH precision coordrefs) value is calculated by subtracting the offset, muliplying by the scale -- For example, {4.551839,0.129920} would map to: ix = ( 4.551839 - -1000000.00093132 ) * 4503599627.37049 = 4503620131225207 iy = ( 0.129920 - -1000000.00093132 ) * 4503599627.37049 = 4503600216672446 Converting the integer back to double is done by dividing by scale and adding the offset, but let's use DB2's offsets and scale for SRID 1: x = ( 4503620131225207.0 / 1000000000.0 ) + -400.0 = 4503220.1312252069 y = ( 4503600216672446.0 / 1000000000.0 ) + -400.0 = 4503200.2166724456 So, now we're at the same order of magnitude, indicating that I'm on the right track... What does your C++ app look like? Do you set the coordinate reference at all? Can you try downloading 'se_toolkit' and report what 'sdequery -v' reports for the same shape? - V
... View more
02-10-2012
04:05 PM
|
0
|
0
|
1476
|
|
POST
|
Now, what is the contents of SRIDs 1 & 2 on Database 2? If you do the math, does the integer representation of {-4.551839,-0.129920} map to {4049780.593044,4049790.639405}? - V
... View more
02-10-2012
03:23 PM
|
0
|
0
|
1476
|
|
POST
|
No, I want you to look at the actual values of the SRID column of the SDE.LAYERS table in the three databases, and then look at the FALSEX, FALSEY and XYUNITS values in SDE.SPATIAL_REFERENCES that correspond to those SRIDs. I suspect there's a discrepancy between the instances, so that the values in one are using the wrong decompression rules. - V
... View more
02-10-2012
01:25 PM
|
0
|
0
|
1476
|
| 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 |