|
POST
|
Registering object classes as versioned will run an Analyze on each table during the process in order to update statistics if none are present. In these cases, running Analyze or dbms_stats.gather_schema_stats prior to registration using Oracle DBMS tools can remedy the issue you are seeing and drastically improve the time it takes to complete. As such, my recommendation is that you give these methods a try in your new database before attempting to register the culprit dataset(s) again. Please post back to let me know if this suggestion helps.
... View more
03-12-2014
05:18 AM
|
0
|
0
|
1903
|
|
POST
|
Despite being a bit older of an article, this might explain the behavior you just described for why some of your datasets may not register as versioned or why they have the 'move edits to base' option unavailable: http://support.esri.com/en/knowledgebase/techarticles/detail/32632 You're using a 10.2 desktop client and a 10.2 geodatabase, right? It was not abundantly clear when I read your last post.
... View more
03-11-2014
07:25 PM
|
0
|
0
|
1903
|
|
POST
|
Glad I could help! Yes, in my case I am equating restart with republish. Technically, I suppose there is a difference. In 10.1 and later (or in 10.0 if you're using an MSD), you are correct... you do need to generate a new service definition first and then restart the service accordingly. So yes, this act of recreating the SD and then 'republishing' it is required to pick up the changes. You don't need to delete and re-create the service itself, though. It would be great if you could mark the correct answer with the green check!
... View more
03-11-2014
04:52 PM
|
0
|
0
|
3209
|
|
POST
|
Can you give some background on your backup database? Is it Oracle 11g R2 with 10.2 SDE as well? What spatial geometry type are you using for your backup database and for the one which you're trying to populate? I have experienced very similar behavior to what you're describing, where a small handful of our datasets took forever to register as versioned compared to the rest. One of those datasets contained a geometric network, and the other had a lot of data compared to all of the others. Our method involved copying and pasting from a 9.3.1 SP2 geodatabase to a 10.2.1 geodatabase, both on Oracle 11g R2. However, our 9.3.1 SP2 geodatabase used SDELOB and our 10.2.1 geodatabase used ST_Geometry. We discovered that the register as versioned process was much faster if we stuck with SDELOB at 10.2.1 instead of accepting the default keywords for ST_Geometry when copying and pasting. I can't tell yet if this is what might be affecting you, but I wanted to share my experiences thus far.
... View more
03-11-2014
04:41 PM
|
0
|
0
|
1903
|
|
POST
|
If the types of changes include inserts (new records), updates (changes to exist records), or deletes (remove records) for the geometry or attribution, then you won't have to re-publish your service as long as your service is dynamic (e.g., not cached). The data should be reflected almost immediately when you refresh the map service. If you are changing schema (e.g., add new fields to an exist feature class, delete a field, re-name a feature class, add a new feature class, modify a subtype and domain), then you will need to stop and re-start your service IF the service contains any feature classes or tables affected by the changes I just mentioned. This isn't an exhaustive list of schema changes, but it's a good initial list to make the point. Additionally, if you add layers to your map document or change symbology or alter the label settings, you'll need to restart your service too. So, in summary, the rule of thumb for whether you need to republish a service or not is this: data value changes (add, delete, update) don't typically require a restart (republish), but schema changes or map document changes do require a restart (republish). I hope this helps.
... View more
03-11-2014
04:30 PM
|
2
|
0
|
3209
|
|
POST
|
By "see" I believe you mean "connect to" in the sense of making the connection from a 10.1 desktop client or 10.1 server application to a 10.2 geodatabase. The answer is yes according to Esri's client-geodatabase connectivity matrix: http://resources.arcgis.com/en/help/main/10.2/index.html#//003n00000008000000 This is the case for direct connections and ArcSDE service connections. Just remember that if you want to take advantage of new functionality available in the 10.2 release of the geodatabase, you will need to upgrade your client or server from 10.1 to 10.2 or higher.
... View more
03-11-2014
08:16 AM
|
1
|
0
|
598
|
|
POST
|
Have been able to duplicate this with two server setups. Wondering if anyone has encountered this problem and found a work around? ArcGIS Server 10.1 sp1, ArcGIS Desktop 10.1 sp1 Using a WebAdapter, or directly to the GIS server Configuration Settings User Store: 10.0 SQL Server (This is a aspnet user store in SQL) Role Store: 10.0 SQL Server Authentication Tier GIS Server Authentication Mode: ArcGIS Tokens If I connect to the rest and log in with a user I see the folders/services that user has permissions to see. If I make an ArcCatatlog connection with that user there is nothing, not even public folders or services available. So you can see everything correctly via the REST services directory, but when making an ArcGIS for Server connection via ArcCatalog you see no folders or services, even unsecured ones. First Question: What type of connection are you making to ArcGIS for Server in ArcCatalog (i.e., Administrator, Publisher, User)? Please verify that you are using the correct type of connection in ArcCatalog for the user account you're logging in with. Second Question: What can you see in terms of folders and services when logging into the ArcGIS for Server Manager (e.g., http://<server name>:6080/arcgis/manager)?
... View more
03-10-2014
05:26 PM
|
0
|
0
|
1017
|
|
POST
|
My apology; the post I made above is wrong and I think this is really what Vince was saying above. Using direct connect syntax with the SDEMON command will not work because that would mean you are trying to use the ArcSDE service daemon to talk directly to the database. I don't believe it is designed to work this way, though other SDE commands do accept the direct connect syntax. Alternatively, you can use SQL to query the PROCESS_INFORMATION ArcSDE system table to obtain information about your Oracle user-schema geodatabase or you can use the tools within ArcCatalog as suggested by Vince and Emad.
... View more
03-10-2014
09:58 AM
|
0
|
0
|
3329
|
|
POST
|
Hi all, I am getting the following error message "Entry for SDE instance not found in services file, Unable to get users" How about telling us which version of Oracle you're running. Are you running the SDEMON command from the database server directly or from a client machine? You should heed Vince's and Emad's advice if you're not using the ArcSDE application service altogether. My post above was simply to provide the syntax that would help from a direct connect standpoint.
... View more
03-10-2014
09:10 AM
|
0
|
0
|
3329
|
|
POST
|
Here are the paths to both the 32-bit and 64-bit SQL Server Native Clients which will work with SQL Server Express 2008 R2: 32-bit http://go.microsoft.com/fwlink/?LinkId=123717&clcid=0x409 64-Bit http://go.microsoft.com/fwlink/?LinkId=123718&clcid=0x409 In your case, I think you would only need the 64-bit client since you appear to be able to connect from a 32-bit app already (e.g., ArcGIS Desktop). I believe it might simply be ArcGIS for Server (64-bit app) that's having issues.
... View more
03-10-2014
08:33 AM
|
0
|
0
|
3050
|
|
POST
|
Here's the syntax required: sdemon -o info -I <{users | users_long | config | stats | locks | vars | instances}> [-q] {[-i {<service> | <port#> | <direct connection>}] [-s <server_name>] | [-H <sde_directory>]} [-u <user_name>] [-p <user_password>] [-D <database_name>] Here's an 11g example assuming your TNSNAMES.ora file is up to date: sdemon -o info -I users -i sde:oracle11g:DATABASENAME -s SERVERNAME -u sde -p password -D DATABASENAME@password
... View more
03-10-2014
08:21 AM
|
1
|
0
|
3329
|
|
POST
|
Here is another possible explanation besides the two I've given above: The machine where ArcGIS for Server is installed is missing the 64-bit client libraries for the specific RDBMS to which the connection is being made. If not already installed, go ahead and install the 64-bit client libraries for SQL Server on the ArcGIS for Server machine. It is important to remember that ArcGIS for Server is a 64-bit application and requires a 64-bit database client, versus ArcGIS for Desktop which is a 32-bit application and requires a 32-bit database client. http://support.esri.com/en/knowledgebase/techarticles/detail/40409
... View more
03-10-2014
06:53 AM
|
0
|
0
|
3050
|
|
POST
|
Are you attempting to register the 'Test' connection file shown in your screenshot under SQL Server Express in Database Servers, or are you attempting to register a .SDE connection file listed under Database Connections? If you're attempting to register a connection under Database Servers, then I think what you're seeing might be expected behavior. Only .SDE connection files are able to be registered with ArcGIS for Server according to this from Esri's online help: You can register any of the following with ArcGIS: Databases accessed through a database connection file (.sde only) Source: http://resources.arcgis.com/en/help/main/10.1/index.html#/About_registering_your_data_with_the_server/015400000505000000/ If you really are attempting to register an actual .SDE connection file, then check the Windows Services console to see which user account is being used to run the ArcGIS for Server service. Does that account have privileges on the folder containing the .SDE connection file? The other possibility is the limitation for administering / managing an ArcGIS for Server instance with a desktop client that is of a different software version. For example, I don't know if you are able to perform certain administrative tasks such as registering data stores if your server is 10.1 but your desktop client is 10.2. Try using a 10.1 desktop client to see if the behavior changes.
... View more
03-10-2014
05:42 AM
|
0
|
0
|
3050
|
|
POST
|
Please provide the version of ArcGIS Server, ArcSDE, and SQL Server that you are using. It would also be helpful to provide a screenshot of the error you are getting. Does the SDE connection file work when trying to simply view the data via ArcCatalog? In other words, is the problem only occurring when you attempt to register the database with ArcGIS Server?
... View more
03-10-2014
05:24 AM
|
0
|
0
|
3050
|
|
POST
|
You can, but you might be unhappy with performance and stability of your various GIS services. Typically, a good rule of thumb to follow is that a single core will support 4 concurrent SOC instances, which often implies a very small handful of very basic, simple services or one semi-complex service altogether. If you plan on having multiple services to be requested multiple times in a row by multiple users, then one core won't work. You'll see poor performance, and you'll likely experience timeouts and errors. Even for development purposes, I would recommend having at least 2 or 4 cores. A single-core machine probably won't cut it. There are plenty of good white papers out there for system architecture planning with respect to ArcGIS Server (at 9.x and 10.x), so I would recommend that you do some research. Another good resource is the Capacity Planning Tool (CPT) developed by Dave Peters at Esri. The only benefit that I can see to having a single-core machine is that your Esri licensing costs will be minimal. ArcGIS Server is licensed on a per-core basis. That being said, you get what you pay for.
... View more
03-09-2014
10:11 AM
|
0
|
0
|
648
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | 04-05-2014 04:11 PM | |
| 1 | 02-19-2014 11:03 AM | |
| 1 | 04-07-2014 12:32 PM | |
| 1 | 04-03-2019 01:46 PM | |
| 1 | 03-31-2021 04:44 PM |
| Online Status |
Offline
|
| Date Last Visited |
07-13-2025
07:13 PM
|