|
POST
|
Great, I'm glad to hear it worked for you. Please mark the correct answer with the green check and have a great day!
... View more
01-21-2014
09:55 AM
|
0
|
0
|
2430
|
|
POST
|
For whichever layer it is in your MXD that you are attempting to hide the OBJECTID field for, try creating a query layer instead and specify the fields you do want in the SQL which comprises the query layer. There is a wizard to create the query layers; you'll need to reference the Esri help if you've not found this option in ArcMap before. You might not be required to actually have the source feature class in your MXD in order to create the query layer... I can't recall as it's been a while since I've done this. If you are required to have it in the TOC to build the query layer, just uncheck it before you publish your MXD as a service.
... View more
01-17-2014
01:25 PM
|
0
|
0
|
2430
|
|
POST
|
Are you attempting to upload a new thumbnail when you see this behavior? I can't quite follow what it is you have edited before clicking the Save button. I've had the same behavior as you describe when I tried to update the application thumbnail by saving the changes. The issue behind my problem was that the image size of my file for upload was too big. The Portal beta release did not have a file upload size restriction, but the 10.2 production release does; most likely that hasn't changed at 10.2.1 also. Try reducing the pixel resolution of your image to something smaller, like 199 x 100 (this is an example, as you'll want to maintain your image aspect ratio of course) and try the upload again. I'm not sure if this helps you or not, but hopefully it does.
... View more
01-17-2014
01:17 PM
|
0
|
0
|
1787
|
|
POST
|
Have you tried building a query layer in your map document with only the fields you want to "see"?
... View more
01-17-2014
12:58 PM
|
0
|
0
|
2430
|
|
POST
|
I have not tried it, but my suspicion is that it will work. Based on the GDB compatibility matrix for 10.2, it appears that client-GDB connectivity is supported for several previous releases. Assuming that same logic still holds true for the 10.2.1 release, you should be ok. That being said, I think 10.2.1 is considered to be similar to a service pack rather than a "new version". Esri is not issuing SPs now in the same fashion as before; instead they are issuing dot releases. So I think a 10.2.1 client should be fine with a 10.2 GDB. I will say, however, that upgrading your GDB from 10.2 to 10.2.1 shouldn't be painful. The leap from 9.3.x is much, much worse than this path. The 10.2.1 Upgrade Geodatabase GP tool should not encounter any new issues that the 10.2 tool did not already. Moreover, it really is best practice to keep everything in the same in terms of release/build numbers. Can you try upgrading in a test database first and use the alter field tool to see how it behaves?
... View more
01-16-2014
02:24 AM
|
0
|
0
|
2419
|
|
POST
|
Did you by chance apply SP1 to your 10.1 installation recently? Before performing the re-installation, please check the Windows Firewall on your server and client to see if it might be running along with any other anti-virus software that could be blocking the 6080 and 6443 ports. You may need to temporarily disable them to see if this does the trick; if so, you can create a focused rule for the ports you need. Also, what happens when you log directly into the server and attempt to request the same URLs from a browser locally?
... View more
12-29-2013
04:11 AM
|
0
|
0
|
2126
|
|
POST
|
When you say ArcSDE 10.1, are you saying that you geodatabase is at the 10.1 release or that you are running the ArcSDE 10.1 application service or both? In other words, I just want to verify that your GDB itself has been created at or upgraded to the 10.1 release that matches the desktop client. In terms of the first error, I've researched the HRESULT code and it does not appear to be documented online from Esri. You may need tech support to help troubleshoot this issue. Have you been able to create, import, and modify metadata for tables and feature classes without issue using the same user account? In terms of the second error, I've seen this quite a bit in ArcCatalog when selecting the Description tab. I don't know if it's necessarily a symptom of or related to the first error you're seeing, though. I've seen this occur for views (and sometimes for feature classes and tables) if there is no well-formatted XML present for that object class. Once metadata is able to be added, that error disappears usually. To answer your question, I believe the answer I can give you is 'yes' based solely on my opinion. I was able to import metadata from a table to a view using the Metadata Importer tool without getting the first error. I also can't find any information online that states that views registered with the geodatabase don't support database so I can only assume they do especially since I don't get the error you are seeing. I did find some older, Esri-documented rules for metadata for spatial views, which are similar to regular views: (1) The spatial view must contain an Object Id column; (2) The spatial view must be registered with the geodatabase; (3) Metadata can only exist for items registered with the geodatabase; and (4) Only the owner of a spatial view can edit the metadata for that spatial view. I think in your case, I think you probably have 1 - 3 covered already but I am not certain about #4. Does the user account you're using to connect to SQL Server via ArcCatalog and ArcToolbox have admin rights (or assigned db_owner role, for example) on the database?
... View more
12-27-2013
01:55 PM
|
0
|
0
|
2814
|
|
POST
|
You can perform a variety of metadata operations on views in 10.1 if you utilize the Metadata GP tools under Conversion Tools. I'm not sure of how you are storing your source metadata, but perhaps something like the Import Metadata tool or the Metadata Importer tool (yes, these are different despite the reversed names) would help you. These are all found in ArcToolbox which can be launched from ArcCatalog or ArcMap.
... View more
12-27-2013
12:58 PM
|
0
|
0
|
2814
|
|
POST
|
Interesting. You might first try adding each of those two lines separately and re-attempting service publishing to see if it's one of them specifically that's causing issues or if it's both of them.
... View more
12-27-2013
12:41 PM
|
0
|
0
|
1188
|
|
POST
|
how to re-establish the connection to ArcGIS Server manager or rest pages ? is there a way to reset the configuration from HTTPS only to HTTPs and HTTP ? is there a way to default back these security changes in ArcGIS Server ? I believe that the HTTP Only, HTTP and HTTPS, and HTTPS Only settings for the protocol under Security --> Config in AGS Manager pertain to the web adaptor, so altering the value as you mentioned should not cause the issue especially since you said that no web adaptor had been configured and your URL requests use a port number. Based on the info you provided, I would suspect the importing of another security certificate to be the culprit for the time being. It sounds like SSL was working just fine for you initially. A few things to try and/or consider first... Did you import a CA-signed certificate to replace the default self-signed certificate in AGS? If so, did you use the importRootorImmediate option or the importExistingServerCertificate option? If it's a CA-signed certificate, take a look at the certification path properties for that certificate and verify that all of the certs in the path (i.e., the root cert, any intermediary certs, and the cert itself) exist in the Trusted Root Certification Authority on the AGS machine. You'll know if all of them are trusted when you view the certification path properties depending on whether or not a red X appears next to any of them. Alternatively, if you need to "clear out" any changes you made regarding the security certificates to get things back to normal per se, you MIGHT be able to try the following: 1. On the server, go to C:\arcgisserver\config-store\machines and open the <servername>.json file (assumes AGS was installed at C:\arcgisserver) using Notepad or Notepad++. Make a backup of the file in the same directory, first. 2. In that file, find the section with "webServerCertificateAlias" and change the value after the colon to be exactly selfsignedcertificate surrounded by double quotes just as you see with the current value. If it's already set to this value, then more than likely you did not try to import a CA-signed certificate into AGS and this most likely isn't your issue. 3. Save the file and then re-start the ArcGIS for Server Windows service. 4. After about a minute following restart of the service in #3 above, try re-requesting the URLs you mentioned to see if the behavior is different. If so, then refer back to the second paragraph of my reply and make sure that, if using a CA-signed certificate, you follow the proper steps to ensure it is trusted on the AGS machine along with any of its intermediary and root certs. If not, then revert back to the backup file created in #1 above and restart the AGS service again since this probably isn't the correct issue and associated fix.
... View more
12-27-2013
12:35 PM
|
0
|
0
|
3338
|
|
POST
|
Yep, I understand you inherited it all... I've been through similar challenges. It looks like the error you're getting is due to the version mismatch to begin with. The command line tools should work just fine for you to make the connection kills. Good luck! Please also mark helpful answers and the correct answer for others who encounter the same types of challenges.
... View more
12-27-2013
08:31 AM
|
0
|
0
|
4510
|
|
POST
|
Upgrading your ArcSDE service to 10.2 would ensure Esri support, and it may help / ensure proper functionality with the admin tools. Either way, you should not mix and match versions in an unsupported or uncertified manner. Remember, too, that if you upgrade your ArcSDE service then your GDB itself must also be upgraded from 9.3.1 to 10.2. The ArcSDE service itself will be deprecated at 10.2.1 just FYI. You can use command line OR the Desktop admin tools from your screenshot to kill sessions. I thought you said that you could kill sessions from the Desktop GUI on the server itself. If so, you don't need to use the command line if it works. But, if you want to use a tool of similar version (or if you don't have Desktop installed on the server), then yes you can use the 9.3.1 ArcSDE command line tools via a command prompt: sdemon -o kill -t <{ all | pid }> [-p <ArcSDE_admin_password>] [-N] {[-i {<service> | <port#> | <direct connection>}] [-s <server_name>] | [-H <sde_directory>]} [-u <user_name>] [-p <user_password>] [-D <database_name>]
... View more
12-27-2013
08:11 AM
|
0
|
0
|
4510
|
|
POST
|
Ok, it sounds like connectivity shouldn't be an issue in terms the fact that you can connect from the server itself. From an Esri software version standpoint, the following article suggests that 10.2 clients are not supported when connecting to 9.3.1 GDBs: http://resources.arcgis.com/en/help/main/10.2/index.html#//002q000000n8000000 I'm not sure if this is exclusive to direct connect and EZCONNECT, or if it includes ArcSDE service connections as well. That being said, could you please disable Windows Firewall and any other firewall / anti-virus software temporarily on your client machine to see if you can connect? In the meantime, go ahead and make your connection kills from the server itself for now.
... View more
12-27-2013
07:55 AM
|
0
|
0
|
4510
|
|
POST
|
Are you certain that the version of your ArcSDE service matches that of your client? Can you connect from the server itself?
... View more
12-27-2013
07:38 AM
|
0
|
0
|
4510
|
|
POST
|
On the machine from which you are connecting with in order to attempt a connection kill, you need to enter the name of the SDE service along with a port number into your services file. The services file is located at the following locations depending on OS: Windows 95 - C:windows Windows 98 - C:\windows Windows Me - C:\windows Windows 2000 - C:windows\system32\drivers\etc Windows XP - C:\windows\system32\drivers\etc Windows NT - C:\winnt\system32\drivers\etc Windows Vista - C:\windows\system32\drivers\etc Toward the bottom, make an entry like the following: esri_arcsde 5152 The esri_arcsde should be replaced with the actual name of your ArcSDE service and the port number should be the same as the port it's running on. Use a tab in between these values. Also, be sure the services file has a blank line at the very end of it so that the ArcSDE service is not the very last line in the file.
... View more
12-27-2013
07:33 AM
|
0
|
0
|
4510
|
| 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
|