Latest Contributions by LorindaGilbert

‎04-03-2019

Hi, I'm having issues with the connection of a V10.3.1 Desktop to SQL Sever 2016, similar to a previous poster with SQL 2012 and V10.1 Desktop - I have already searched the forums and checked all the recommended items. Yes, I am well aware that V10.3.1 is not certified to work with SQL 2016; however, neither is V10.2.2 and we have that running on an OS 2016/SQL 2016 box (legacy software that can't be upgraded as of yet). My issue is extremely vexing to me and obviously ESRI support as well - I'm at level 2 support right now with my support ticket. I am reaching out to the community to see if anyone else has run into this issue. I can connect with V10.3.1 to three different servers with OS 2016/SQL 2016 on them that were built approximately 6-9 months ago (maybe longer) with a VM template. I do believe that the VM template was tweaked between those builds and the current version of the template. All of the servers built on the current VM template OS 2016/SQL 2016 are unreachable with V10.3.1 UNLESS SSMS is installed or the newest V10.6.1 is installed! It is not the driver for SQL 2016 from ESRI download as ArcPro can connect to all of the servers - old and new alike. I've been inspecting the Local Security Policies and haven't found any differences. Also a mixture of V10.2.2 SDE, V10.3.1 SDE and V10.6.1 SDE on these various servers. The sdedc_SQL_Server.log has: CAN'T OPEN INSTANCE: sde:sqlserver Spatial Engine Connection Failed (-409) Cannot Get Access to Instance sde:sqlserver Creating OLE connection in ArcCatalog gets: [DBNETLIB][ConnecitonOpen (SECDoCLientHandshake()).]SSL Security error. Checked Registry on desktop machine TLS is not listed in SecurityProviders at all Checked Registry on server TLS 1.0 and 1.2 are listed in Security Providers TLS 1.0 as Enabled 0, Disabled by Default 1 TLS 1.2 as Enabled 1 Upgrading to V10.6.1 IS NOT a complete option for us as we have some users with legacy software that will not work with anything newer than V10.3.1. Also, installation of SSMS on these machines is not an option either, as these folks have no business with that installed. Items checked so far: Windows Defender (firewall) turned off - security policy as we use Symantic .NET Framework 4.5.x installed on server .NET Framework 4.7.x installed on desktop One instance of SQL on the server Can ping the servers Can connect to SDE via SSMS or ArcCatalog on server using either AD or SQL logins Cannot connect to SDE via ArcCatalog on Desktop using either AD or SQL logins One server has SQL 2016 SP2 installed, others are at SP1 MS ODBC connection from client machine works fine TLS 1.0, 1.1, and 1.2 are checked on for client machine, SSL 2.0 and 3.0 are unchecked TLS 1.0, 1.1, and 1.2 are checked on for server, SSL 3.0 is unchecked Thanks for any help that can be offered. L~

‎02-06-2015

Hi All, Not sure that this is the correct location for this question, feel free to move it. Has anyone run into a specific user's machine being listed as having an ArcMap license OUT at a specific time and then in being IN approximately 30-40 mins later. The kicker being that this user is NOT in ArcMap nor ArcCatalog at the time. This is also occurring every hour at one minute past, starting at approximately 3pm and running until midnight. We are not sure if it is starting earlier in the day as of yet. We only discovered it this week - who know if it has been occurring before now. The license manager was just recently bounced, so the logs have be reset. Any ideas on what to look for? Thanks.

‎10-10-2013

Hi All, I'm getting this same error, but only when I attempt to have it process the invalid photos (the ones missing gps coords or invalid elif metadata. If I don't include a location for these photos, it runs fine. I'm in Win7, ArcGIS Standard 10.1 SP1. Any help here? Thanks.

‎09-27-2013

Not quite sure how/why it does it, but I have in many mxd's the workspace is referencing a database connection string that is no longer in service, you see this by exposing the workspace path or using ArcCatalog's repair data source. However, we are getting the data due to the last time that we went through this exercise (there have been at least 4) there were no nice scripts out there to do bulk updates (and the ArcCatalog repair datasource failed miserably), so the repair data source in ArcMap was used, the mxd saved and we went on our merry way. Fast forward to today, our mxd's still show these long outdated workspace paths but source the current database on the old server. In Python, you can only read the service properties but not update them (sure would be nice to be able to update the service properties, hint, hint ESRI) - so my workaround was to update the workspace path no matter what it said (of which some were pointing to directories that were created on our XP machines - we are now on Win 7; so you know those directories no longer exist; some on my machine were also pointing to a directory from someone else's XP machine that is also long gone!), but rely only on the sde service type and the database name that the service property said was being sourced to update only the one changing. Interestingly, all of our database iterations have had the same name, just different server names, so it happens to work out. In the future if we change db name as well as server, it may not work.

‎09-27-2013

Michael, I had in the original script to at least let the user know that there are broken links (we still had some mxd's from two and three servers ago!!). It would alert the user that there was a problem with certain data and then continue on. Once the db was turned off, ALL feature classes were broken links and it wouldn't change anything at all. I was mainly putting the info on the forum as a warning to others to run these types of scripts before the db is turned off so that it has a better change of running properly. With any luck, in future versions of AG and ArcPy (we are running 10.0) they will handle stuff like this better because sometimes you don't have the choice of being able to turn a db back on - especially if the server died completely and you had to move the db to another server. You also don't always have to option of naming a server the same name. So for now, I've turned the db back on for a few days to allow for the users to get to the directories with many mxd's (several with over 100) changed over. Any others that are looked at later, will just have to use the repair data source option within ArcMap. Thanks.

‎09-27-2013

Grrr... Has anyone else run into this? I turned off the old db last night and we attempted to run this script that I had created and NOW it doesn't change anything! Yet it worked very well with the db on prior to this. Have since turned the db back on and now the script works. So warning to all that may be looking into this - make sure that it is done with both databases and servers up and running. If someone has managed to run a python script to replace the data source with the old source off, please let me know how you did because we are likely to run into this again. Thanks.

‎09-26-2013

Currently in the TOC List by Source tab, it gives the version name from the database and the connection type (which with the advent of ESRI recommending Direct connections makes this somewhat irrelevant now), then under this shows the feature dataset (if applicable) and then the feature class name as it has been changed to in the TOC. In our case (and likely many others as well) when we change servers for our data, we keep the same data owner, data schemas and database name and just create a copy of the database on the new server. When changing the data source to the new server (unable to effectively do so with python scripting due to bugs in the extents on layout windows), in this tab, everything looks the same after the change. So without opening each feature class to check the instance for the data source on the properties source tab, you don't know if you've updated the feature class to the new server or not - MANY CLICKS OF THE MOUSE. We also have several mxds that are published map services that inadvertently got some feature classes added via the data owner rather than the data viewer to the mxd. To compound matters more - we use SDE schema and the DEFAULT version in all of our databases AND we use replication from a master editing database. Therefore, the same feature datasets and feature classes are in the editing database and the data repository. Only the database name and the data owner are different - but not everyone pays attention to that detail. Most only know that the editing database is on a different server. It would be nice to see the server name and the user name connected on the same line as the version name. The TOC on this tab already sorts based on the database name, server name and user name, it just doesn't show this information.

‎09-24-2013

Hi All, Has anyone created a data model or a python script that will publish a map and data package for Publisher? I have searched the forums and the help file for anything that could be used, but either I'm not putting in the proper search terms or they don't exist. Please advise and point in the right direction if the ability is out there. Thanks.

‎09-23-2013

I was able to use this portion of script inside of another python script that looped through the mxd's table of contents and data frames and it was able to find the database and service type so that I could change only the ones that were pointing to the server being changed. We are also changing servers for one database and the .sde could be named anything thanks to ESRI embedding it in the mxd as a workspace path that doesn't have to relate to the current reality (have even found references to .sde's on other editor's machines that are not even working here any longer! and servers that were retired years ago! and it saved the path to our .sdes that were created on XP machines and we are now in Win 7 - therefore different user locations). Now that I am attempting the SAME methods on individually saved layer files, IT DOESN'T work, it reports the workspace path and datasource, but when attempting to use the database and service type properties for further refinement, the script bypasses the find and replace workspace path portion of the script completely - it is NOT getting the information. From the earlier post from jbarrette, this appears to be a bug in 10.0? If so, this is the second bug that I have run into with python scripting for just a simple server change, and each were found through the forums but not on the known issues page of the support. We are currently using Arc10.0 with SPs. Arc10.1 is not an option for us at this time.

‎09-19-2013

Just checked my data driven pages mapbook which has groups within groups, and it appears to have handled them like a champ and changed them to the new server. Of course, when I turn the old database off next week, I may be eating my words 😛 . But the source properties are showing up as I would expect if I had manually changed the data source.

‎09-19-2013

I didn't put anything special into the script to look for a different type of feature class. Here's a slightly modified copy of my script (to protect the innocent :cool: ). I did use parts of other scripts that I found on the forums and on the resources page. I do intent to make this script much more flexible for future use. We have several SDE servers here, so being able to have a flexible script is a must. Hope it helps you. I also intend to create another script that will go through the layer files that we have saved for general use - next item on my list.

‎09-19-2013

I found one mxd that was using an annotation feature class, it does appear to have changed it according to the source under properties.

‎09-19-2013

That's a good question, I'm not sure. We don't have that many layers of annotation. The one mxd that I know has annotation is coming from a data source that wasn't changed. I'll have to look through some of the 200+ mxds to see if any have annotation. I'll do it the 'easy way' by looking at the text file that I had written out to show what was changed and if any broken links in the mxd. I did notice that if there was a very old data source listed that no longer exists, it was less likely to change them and reported them as broken links. I'll get back with an update in a bit.

‎09-19-2013

Good Morning, Thanks for the reply. Using V10.0 SP2. I'm testing whether changing your default printer makes a difference, but that is an added step for the users. Some of my users are not as computer/ESRI savvy as the rest of us and I'm just attempting to make the server switch easier for them (which there will be more in the future). This is NOT accomplishing this goal. I have reported as a bug and related it to the issue NIM092164 too. Thank you for letting me know that it had been reported and needed more reports to maybe get them off the stick and get it fixed. I too will be upgrading to the newer releases, but luckily, this will be after this server change. I agree that it is a bug that SHOULD be fixed. There is ABSOLUTELY NO REASON for the printer and layout settings to be changed if you are not touching the layout window or doing anything with printing. Or there should be a way of finding the printer and layout settings in Python to be able to be retained during updates. The test for changing the default printer was minimially productive. Most of our maps are either printed to a large size plotter or to Cute pdf writer. If you use this pdf writer as the default printer in the windows system, then it will keep the pdf writer as the default, but still changes it to be the 8.5x11 size paper, but does retain the custom size the Map Page Size. Interestingly, if you set the default to your plotter or to Adobe pdf printer, it changes the extent to 8.5x11 for both the paper size and the map paper size. GRRRR Thanks.

‎09-18-2013

Hi All, Any idea on this? I've noticed it as well and can't deploy a script that is supposed to fix things to have it break something else. I've noticed that it resets your printer back to your default windows printer. So if we had a mxd with a layout set to 36x68 on our plotter or a pdf writer, then after changing the source data, the layout is now set to our default laser printer at 8.5x11. Not cool. We are using Arc 10.0. As the orginal poster noted, why does the printer settings get changed when all you are changing is the source of the data? Especially when this data is a duplicate of the previous data source? Thanks.

Online Status	Offline
Date Last Visited	‎01-12-2024 09:28 PM

My Ideas

Latest Contributions by LorindaGilbert

Geodatabase Connections

ArcMap opening every hour then closing

Re: Help. I am receiving error 999999 when I try GeoTagged photo to points. Confuse

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

Server info in TOC

Automating Packages

Re: layer serviceproperties does not support SQL Server direct connect

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

Re: Looping Through Layers in Mxd and Saving Mxd Changes Extent

Re: ArcGIS Pro Set/Update Data source for all laye...

Sort order of Related Table in the pop-up

Re: Arcade error : FeatureSetByPortalItem cannot b...

One of several Attribute Rules not calculating as ...

Re: Publishing Survey using fields that are Non Ed...