Latest Contributions by Karyn_Kerdolff

I'm experiencing this issue. Has a solution been found?  ... View more

Thanks for the links. At first it didn't work, but after getting on the phone with ESRI and truncating away any locks, I realized I was looking for the table in a feature dataset, when it was really living at the "root" of the SDE. I don't know if it was there after I first tried the steps above, or after working with ESRI, but it's back and working nonetheless. Not-so-pro-tip for future reference: the re-created feature class won't show up in a feature dataset, so don't forget to look through the whole catalog tree for it. ... View more

Five months later, and after switching organizations, I've come up against hangups that exhibit very similar behavior to what I first reported. It seems like something isn't releasing the UI after certain tasks are completed. Environment ArcGIS Pro 2.2.3 Windows 7 SP 1 Xeon E3-1275 v2, 24 GB Ram, Quadro K200D MS Active Directory network Dataset Utah Road Centerlines feature class from the state GIS clearinghouse: Roads and Highway System  I've confirmed that subsetting the data to Salt Lake County via DefQuery/Export, and then subsetting further to major roads via DefQuery/Export, does not change the behavior (it is a large feature class, but the major road subset only has ~7000 features). Behavior Certain actions cause the interface to go unresponsive or extremely slow when working with the centerlines: Opening the project for the first time. Making any symbology change that would update the map (clicking Apply Symbology, changing from Single Symbol to Unique Values, dragging layers around in Symbol Layer Drawing). Running the Import Symbology tool to apply symbology to the centerlines feature class. Running field calculator on a field in the attribute table (same behavior as originally reported). After these actions, the interface goes unresponsive for a split second as normally happens. The map pane will refresh to display the updated symbology as expected. However, the icons in the ribbon stay grayed out, as do the icons at the very top (Save/Open/New, Undo/Redo). The cursor displays the spinning progress circle when I move it anywhere around the interface EXCEPT for the map pane, where it displays the Explore finger. Navigating around the map pane at this time is extremely slow, as are any identify operations. Sometimes an inadvertent click to identify an area not covered by the feature class causes a full hang while the Identifying progress bar appears indefinitely, requiring a full End Process to recover (and subsequent loss of any unsaved work).  As the interface is hung, Task Manager reports ~25% CPU usage while the ArcGIS Performance Monitor does not report any hangs or any real activity (as noted before). Pausing the map pane does not change the behavior. Without pausing, the map pane updates as it should so it doesn't seem to be related to the actual drawing of the data. Workaround Once the interface hangs, if I switch the map pane over to the catalog and then back to the map pane (using the tabs at the top of the map pane) it "releases" the full interface and everything goes back to normal. This works for small one-time changes, but doing this every time I move a layer in the Drawing Order is just painful (and frustrating when doing it five times, then having it hard hang and lose all that work because I didn't save after every layer move). Troubleshooting I've tried the following different scenarios with no changes: Project saved on a network drive, feature class saved in GDB saved on a network drive. Project saved on a network drive, feature class saved in GDB saved on a local drive. Project saved on a local drive, feature class saved in GDB saved on a network drive. Project saved on a local drive, feature class saved in GDB saved on a local drive. With the project saved on a local drive, I've tried it against a copy of the feature class I downloaded two weeks ago, subsetted to Salt Lake County, and put in a network-based GDB; exporting this copy to a local GDB; re-extracting the downloaded GDB from the zip folder into a local folder; and downloading the GDB anew and extracting it into a local folder. None of these variations showed any difference either. Other feature classes in the network-based GDB rarely exhibit the same behavior. I don't remember what dataset I was running into problems with on my original post, but there is a better-than-not chance it was a download of the same feature class. I have the project packaged in a small (<2mb) package that I can send by e-mail if anyone wants to try reproducing the problem. ... View more

After working with tech support, we've got a working theory about what's going on here. It appears that ArcGIS Pro really doesn't like our Novell network shares (ArcGIS Pro Export to PDF: PDF Won't Open in Acrobat ). Based on the evidence that Pro doesn't seem to be properly closing file connections when writing PDFs to Novell shares, my theory is that there is a bug/error/incompatibility with writing any data to Novell file shares. The .aprx file for my project is stored on a Novell file share, and it uses several feature classes from a file GDB stored on the same network directory. Perhaps when I open the project there is a file connection somewhere that isn't properly released and starts chewing up memory. I'll do more testing when I get the time to try to narrow down the issue, but for now I'm going to assume that anything ArcGIS Pro-related that is stored or referenced on our Novell network is unstable.  In my limited testing of the PDF issue, Windows Server-based network shares seem to work as expected. ... View more

Josh, I've not tried a Google Drive/OneDrive/other-cloud-service export, but I suspect that it should work fine as long as it writes to a local directory that then gets synced to the provider's server. In my testing, exports to a local drive and to a Windows Server-based share work as expected. The problem appears to be writing to a Novell network share and not necessarily Acrobat (though I don't know why other PDF readers are more tolerant of the extra null data at the end of the file than Acrobat). ... View more

Mark, the more I dig the more I'm suspecting my office's OES (Novell) network environment. Do you still have the same error if you export to a local directory instead of a network directory? Do you see the same NUL characters at the end if you open the PDF in Notepad++ (or your text editor of choice) with 'Show All Characters' enabled? ... View more

Ok, this gets curioser and curiouser.  I normally export my PDFs to a network location mounted via OES (the old Novell network directory and file server). When I export there, it gives the error as above. However, if I export to a local directory (c:\temp\file.pdf), they usually export just fine. There's no change to the project between the two exports; it's literally one right after the other.  Opening a PDF (or JPG or SVG) exported to the network location in Notepad++ reveals a host (thousands, sometimes more than 10,000) of NULL characters at the end of the file after the %%EOF line. PDFs exported to a local directory do not have these NULL characters, nor do ArcMap 10.4 network-exported PDFs. I'm waiting to chat with IT to see if they have any inkling of why they are being added to the end of the PDFs. If I delete the NULLs from the network-exported file, it will open in Acrobat. However, when I close the document it will ask if I want to save my changes. If I do so, it then passes the PDF 1.7 check. The locally-exported PDFs fail the 1.7 check as above but still open fine (and don't ask to save changes at the end). I am having a hangup on one very complex layout (36"x48", tens of thousands of features, lots of transparency) that will open in Acrobat (locally-exported) but immediately freezes whenever you try to zoom or pan. I'm still trying track this one down. Would someone mind running the 1.7 check (https://www.pdf-online.com/osa/validate.aspx) on one of their PDFs exported from Pro to see if they get the same errors as above? It would be interesting to know if everyone gets the 1.7 errors or just me.  ... View more

Thanks for this bit of detective work; it's interesting that my installation of Pro is fumbling the creation process like this. After working with Kory, I've opened a support case to try and figure out what's going on. I'll report back here when we figure out what's up. ... View more

One workaround I've come up with is to use an Offset effect on the stroke layer of the rectangle. Set the stroke to be the same color as the fill Leave the Offset distance to 0 pt Chang the Offset method to "Round" Experiment with the Stroke width to get the corners you desire This isn't perfect, and you have to play with the size of the original rectangle as well, but it should give you something until ESRI fixes/implements the functionality. Dan Patterson, it seems like that dropdown only changes what the example swatch looks like, rather than effecting the actual polygon (as evidenced by the wildly irregular polygons included in the dropdown). Is this correct? ... View more

Kory, I've just sent it off to you (after learning the adventures of trying to create packages with large gdb's attached). It's been happening with every project I've tried to export, whether simple or complicated.  Adrian, I've tried just about every setting in the Export Options dialog box, but none of them have any impact. ... View more

I haven't yet; I need to get my account connected to my organization this morning and then I'll open a case.  I'll try and post back here if we find anything. ... View more