|
POST
|
No ArcSDE user ever requires unlimited tablespace or execute any library. SE_layer_create is an API call -- the same call functions the same without regard to database vendor. If your instance doesn't perform in accordance with the documentation, please contact Tech Support for assistance. - V
... View more
01-18-2012
09:57 AM
|
0
|
0
|
2324
|
|
POST
|
I can give you my procedure, but it won't you do any good -- I've done so many ArcSDE Oracle installs, I no longer even need to watch what my fingers are typing. I doubt I issue the same commands in the same exact order in any two installations, but I almost never encounter an error. My procedure is: Create the database Create the SDE and data tablespaces Create the SDE and data-owner users Create the necessary roles Grant permissions Install ArcSDE software Patch the ArcSDE software Create the service with the 'sdeservice' (Windows only) Edit the $SDEHOME/etc and OS etc files Run sdesetup to create the instance (I never use the GUI) Revoke SDE user permissions and re-GRANT the minimum necessary Start the service Configure the listener Load data If you need cookbook instructions, you should follow the steps in the documentation. If the documentation is incorrect, or you encounter some other failure, then you should contact Tech Support for assistance, and/or use the troubleshooting how-tos to work around the issue. The key thing is to start doing, because you could spend weeks reviewing special case documenation without making any real progress. Good luck. - V
... View more
01-18-2012
09:49 AM
|
0
|
0
|
1919
|
|
POST
|
The documentation defines the necessary permissions for a data owner in Oracle. Similar pages exist for the other supported databases. While it may seem useful to attempt layer creation as the SDE user, it also increases the probability of corrupting the entire instance. In practice, I usually restrict my SDE user privileges to *less* than that of data owners, so the attempt would be all risk and no possible gain. In an instance with more privileges, the risk increases, but it stilll wouldn't solve the issue for the proper privileges for a data owner account. - V
... View more
01-18-2012
09:13 AM
|
0
|
0
|
2324
|
|
POST
|
They're both the same procedure, though the 10.0 Help link has more details. I should point out that this is not an optimal install option. If you can't run the ArcSDE on the database server, you should probably not run an application server at all (use Direct Connect excludisvely). You should always install ArcSDE binaries on the Oracle server(s), even if you don't execute the post- install, so that you have a cleaner solution when it comes time to apply a service pack (I'm not a fan of copying DLLs). - V
... View more
01-18-2012
07:38 AM
|
0
|
0
|
1919
|
|
POST
|
Lance has indicated that fixes for both are in the next release. - Vhttp://forums.arcgis.com/threads/45342-Row.SetDate()-throws-exception?p=157413&viewfull=1#post157413
... View more
01-18-2012
06:27 AM
|
0
|
0
|
625
|
|
POST
|
The precision of an ST_GEOMETRY object is defined by its SRID. The ST_UNION operator should handle the merge of overlapping geometries correctly. You should start an incident in the ArcGIS Server REST API queue if the display precision is causing topology problems. - V
... View more
01-17-2012
10:56 AM
|
0
|
0
|
2273
|
|
POST
|
Doh, yes, XYUNITS 10000 (0.1mm). The problem *is* with the REST API, but it's more a simple issue about representing some double values in text (and vice versa), which is why the n.9641999993 and n.3638000004 values exist. Given that the geospatial object's precision is at the thickness of a human hair, and the imprecision is at the magnitude of the length of the covalent bond between carbon atoms, I doubt it's really worth pursuing. - V
... View more
01-17-2012
07:01 AM
|
0
|
0
|
2273
|
|
POST
|
If you inspect the SRID of the ST_GEOMETRY layer, I'm sure you'll find it has been created with an XY_SCALE (resolution) of 1000 (1mm). If so, then you *are* getting the complete value in SQL (and an imprecise one through the REST API). If you wish greater precision, you'll need to specify it at layer creation. But be sure you understand the storage and performance ramifications before you ratchet up the precision (greater precision decreases compression efficiency, slowing access proportionally). It would also be useful to compare the desired precision with the actual accuracy -- most geospatial data isn't more accurate than a decimeter, much less a millimeter, so displaying it to angstrom resolution is more than just a violation of the Heisenberg Uncertainty Principle. - V
... View more
01-17-2012
04:07 AM
|
0
|
0
|
2273
|
|
POST
|
In the long run, external users really ought to be using a SSL/VPN solultion, since SSL also provides greater security than a firewall, reduces the risk of a DOS attack, and encrypts the data in transit. - V
... View more
01-13-2012
03:36 AM
|
0
|
0
|
1361
|
|
POST
|
You only need 5151/tcp open if you're using it as an application server endpoint. Direct Connect connections use whatever the RDBMS uses. The default ports are documented, but some sites use alternate ports, so you really need to inspect the configuration. - V
... View more
01-12-2012
12:47 PM
|
0
|
0
|
1361
|
|
POST
|
You don't need to do anything yet. I augmented the 'se_toolkit' shpfile.lib to support read access back in August, so I just need some hobby time (when not working weekends or repainting the bathroom) to modify the 'asc2sde.c' template into 'shpfile2sde.c'. The first iteration won't support column renaming (-a file=...), but basic '-o {create | init | append}' should be doable. I'll let you know when 'setk100b10' is released (hopefully before 10.0sp4 ships). - V
... View more
01-12-2012
07:23 AM
|
0
|
0
|
2786
|
|
POST
|
You can certainly add a new *table* to an actively published database, but featureclasses are geodatabase objects, and are subject to locking by Server (espcially when they participate in a feature dataset). While the term "versioning" can mean many things, in the context of ArcSDE it does not mean what it would have to for "creating the new feature class in a different version of the geodatabase" to work. A versioned geodatabase is driven by a state tree. All tables participate equally in the state tree. It is not possible to place a table in a different version from the rest of an instance, because a "version" is only a named state, and all tables can participate in a single state. What are you trying to accomplish by adding a new featureclass? If you provide more details, we may be able to provide better guidance. - V
... View more
01-12-2012
04:13 AM
|
0
|
0
|
2628
|
|
POST
|
The FGDB API is really designed for those who don't have ArcGIS available. It's hard to believe that C++ is an easier way to whip up a report when you have Python available in Desktop, especially if you hope to place a map in your report (there's no mapping at all in the FGDBAPI). - V
... View more
01-11-2012
05:22 PM
|
0
|
0
|
681
|
|
POST
|
It's never been best practice (or even supported) to edit views outside of ArcSDE's ken. It was, however, the only way to solve some situations before the advent of native datatypes like ST_GEOMETRY. The 'sdetable -o create_view' command was created for the purpose of managing the F and S views associated with SDEBINARY and SDELOB storage layers. Given the choice of a supported 'sdelayer -o register' after creating the exact view you need and the unsupported editing of a view which lacked the ability to use most of the capabilities of SQL, I would think the former would be more popular. In fact, SQL administration is one of the most compelling arguments for using ST_GEOMETRY (it's not the *easiest* way to administer an instance, which is probably why it's not emphasized). I've never heard of performance issues associated with view implementation -- If the optimizer is going to choose unwisely, it will do so for what seems to be valid reasons, and it will do so for both types of creation equally. If anything, the ability to include hints in custom view creation is another strong vote for SQL view management. Permission errors are exclusively in the domain of RDBMS implementation. Whenever user A tries to create a view with user B's table, they must have GRANT OPTION access to the source table to grant access to other users. This is required by the SQL language. I can't imagine what harm could come from granting SELECT WITH GRANT OPTION to a data ownership account with restricted use and a closely held password (another best practice). - V
... View more
01-11-2012
04:03 PM
|
0
|
0
|
2855
|
|
POST
|
If push comes to shove, I think I could extend the Generic SDE Loader in 'se_toolkit' to read a shapefile in a simple table loader ('shpfile2sde'). Basic functionality isn't more than a day's effort, but if you're dependent on "insert_or_update" or some of the more exotic capabilities, you'll probably want to work this from the Marketing/Tech Support side for a supported tool. - V
... View more
01-11-2012
09:17 AM
|
0
|
0
|
2786
|
| 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 |