|
POST
|
There is no correct answer to this question. For some users, Direct Connect will be the best solution. For others in the same exact configuration, an application service may be. The best methodology is to choose one, get a feel for the performance characteristics, then use the other to compare. Note that you may need to revisit the problem if the number of clients changes by more than 50% (maybe even 10%). - V
... View more
10-12-2011
03:29 AM
|
0
|
0
|
919
|
|
POST
|
This might be an artifact of the GEOGRAPHY restriction against antipodal construction (if the search window exceeds 180 degrees of longitude, the search will fail). I'm not sure how you're going to meet the GEOGRAPHY requirement when multiple countries occur in more than one hemisphere. - V
... View more
10-11-2011
12:17 PM
|
0
|
0
|
1159
|
|
POST
|
I'm glad it worked. I didn't think it applied in your situation, but I needed the caveat in place, just in case some later viewer of the thread came to my boss with "Vince said I should drop the SDE user and now my database is corrupted." 😕 - V
... View more
10-11-2011
07:23 AM
|
0
|
0
|
2298
|
|
POST
|
If it's an initial install that I hosed, I generally DROP USER SDE CASCADE and start over. NOTE: IF YOU DO THIS ON AN INSTANCE WITH ST_GEOMETRY DATA IN ANY USER, IT WILL IRREPARABLY HARM YOUR ORACLE INSTANCE. - V
... View more
10-11-2011
06:30 AM
|
0
|
0
|
2298
|
|
POST
|
This is more of an Oracle restriction than an ArcSDE issue -- A DISTINCT query on indistinct features (object type columns) cannot succeed. I expect that SDO_GEOMETRY would have the same issue. If you eliminate the geometry column by turning it into text, you'll corrupt the geometry result registered with ArcSDE. You might have better luck with GROUP BY, but then you'd need to do an expensive geometric UNION with every query. If you can fashion a DISTINCT query without the geometry, you might be able to join the geometry later (either through inline views or a view on a view). I note that you're using the SDE user to own and manage spatial tables (or at least the resulting view). The SDE user and SDE tablespace should really be reserved for ArcSDE configuration and management, much the way the SYSTEM user and SYSAUX tablespace are reserved for the database. It is best practice to avoid use of the SDE user for anything except ArcSDE management. The use of 'sdetable -o create_view' on ST_GEOMETRY tables is also outside best practice. 'create_view' was designed for SDEBINARY/SDELOB storage -- the best way to construct spatial views on ST_GEOMETRY layers is through SQL with CREATE VIEW, and to register the results with 'sdelayer -o register' (which will also verify the uniqueness of the query [by NUMBER(38) registered rowid column] at the time of registration). - V
... View more
10-11-2011
04:29 AM
|
0
|
0
|
2837
|
|
POST
|
"Database Connections" are to Enterprise ArcSDE servers. "Database Servers" are Personal and Workgroup ArcSDE (MS SQL-Server Express) instances. The documentation has the details. - V
... View more
10-11-2011
03:45 AM
|
0
|
0
|
2282
|
|
POST
|
ArcGIS Server licensing is by the server on which it runs [except when in a VM, in which case it's on the lesser of the CPUs on the physical host(s) or the sum of the CPUs in the virtual host(s)]. Futher licensning questions should be directed to Customer Service or your local marketing rep. - V
... View more
10-11-2011
03:21 AM
|
0
|
0
|
2396
|
|
POST
|
You could use the same procedure for hacking the SHAPE and FID columns in the business and 'Fn' tables in an SDELOB storage layer (Sn could be fixed by placing the layer in LOAD_ONLY I/O mode), but this is much riskier. You might be better off reloading the table with ST_GEOMETRY storage (which would eliminate the Fn/Sn issue) -- some of my colleagues used 'asc2sde' to load a 340 million row table in only 22 hours, so the reload in the new format might take less than a day. - V
... View more
10-10-2011
05:30 AM
|
0
|
0
|
2596
|
|
POST
|
Best practice is to leave the OBJECTID alone; if you move up to a real RDBMS and ArcSDE technology, you'll need to adhere to this guidance more closely. The same goes with GUIDs -- they only impact performance significantly when you venture into the "large" table range (hundreds of thousands to tens of millions of rows). Keep in mind that personal geodatabases are deprecated, and will not be supported by 64-bit ArcGIS 10.1. - V
... View more
10-09-2011
03:34 PM
|
1
|
0
|
2636
|
|
POST
|
The 1.1 API was released in August. Lance's "sticky" post details the changes and other posts detail issues that have been found with the .NET API. - V
... View more
10-09-2011
08:38 AM
|
0
|
0
|
2621
|
|
POST
|
While file geodatabases can store rasters, the FileGDB API is documented as not supporting them. You can certainly store any bytestream in a BLOB column, but that will not generate a RASTER type column. ArcObjects can be used to load rasters programatically. - V
... View more
10-07-2011
04:21 AM
|
0
|
0
|
651
|
|
POST
|
Use an integer column, but not the objectid. Don't use a GUID unless you *really* need certified uniqueness, because the keys are scrambled in a way that provides poor performance for parallel join operations. - V
... View more
10-06-2011
03:21 PM
|
0
|
0
|
2636
|
|
POST
|
The main problem with drop-and-replace on the sequence is that the sequence reader is probably going to use MAX(objectid) to trash your effort. 200M features is a lot of features to reload, so you might look at creating a NEWIDS table that pairs the orginal OBJECTID with "rownum as new_oid", then UPDATE using that driver table. THEN you can replace the sequence. For the future, you might consider using partitions to manage the aging process, with LOCAL indexes to keep them valid when you lop off the aged out fragment (the "delete" is instantanous, and you can organize the temporal chunks to reduce spatial fragmentation and swap partitions instantaneously as well -- nothing quite like a highly performanant very large table!). - V BTW: The limit on a 32-bit integer is 2^31-1 -- -2^31 is the signed minimum and 2^32-1 is the unsigned maximum.
... View more
10-05-2011
04:04 PM
|
0
|
0
|
2596
|
|
POST
|
What license(s) have you purchased? ArcCatalog is used to create Personal and Workgroup instances (local to the ArcGIS install). The Enterprise ArcSDE media is separate from the AGS and Desktop media. You cannot use a workgroup license to authenticate an Enterprise ArcSDE install within Oracle. You might be better off contacting Tech Support or your marketing rep to help resolve this issue. - V
... View more
10-05-2011
12:45 PM
|
0
|
0
|
828
|
|
POST
|
Personal and Workgroup ArcSDE are only available as SQL-Server Express instances. Only Enterprise is available with Oracle (and the other RDBMSes). If you are using Personal or Workgroup, you don't have to worry about virtual host deployment, since they're Direct Connect-only. Only Enterprise supports an a application server service. If you do license Enterprise ArcGIS Server, you'd have to license an additional server host to run the application server on a host other than the AGS host. - V
... View more
10-05-2011
11:00 AM
|
0
|
0
|
828
|
| 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 |