Latest Contributions by DavidBollinger

  Existing concurrent licenses could fail (ie be unable support latest release of Pro) sooner than 2026.  The "10.1 - 10.8" block of ArcMap concurrent license that also licenses up to latest (currently 3.3) Pro may only go so far, and is the last version of Desktop license that we'll see.  (just as the prior license block for 10.0 only went "so far" (edited, bc version correlation may have been wrong, but those details aren't important))   For example, upon the release of "Pro 4.0" (could be even earlier, whatever version cut-off they choose) it seems reasonable to expect that ALL former "you get Pro with Desktop" licensing would fail - because there's no more Desktop concurrent licensing AT ALL* as of 7/1/2024 (e.g. don't expect a "Desktop 10.9" license that includes "Pro 4.0").  I get that, we all know Desktop is going away, and has been expected, but they're closing doors on existing licenses in other ways sooner than expected.   *That also means existing licenses can't be upgraded either - which is how I learned about all of this in the first place, while attempting to upgrade a Desktop+Pro from basic to advanced.  I did literally ask regarding a supposedly "grandfathered" concurrent license, and was told that the ONLY WAY forward was to acquire a Prof+ named license. ... View more

Hi Sherri, I feel your pain - or likely will soon.  We're a rural County with 16Adv, 9Std, 4Bas, all concurrent, and current maintenance for those is right at $40k/yr.  I've not yet heard officially, but I've "done the math" just as prep, if forced to convert to subscription.  As of today:  16*4200+9*2200+4*700 ~= $90k.  About a $50k/yr increase, ie more than double.  It already feels like our GIS is operating on a shoe-string budget, so I have no idea how we'd manage that sort of increase.  (and last time I checked, a suitable ELA was FAR outside our range, so that's probably still not a viable alternative either) ... View more

FWIW (very late reply)...  The direct url format given above is correct, but it's for a mapservice, from a server; not for a webmap, from a portal.  To retrieve portal data via a direct url, you'll first need to know its itemid (snoop around a bit).  AND, it needs to be shared publicly (or you'll have to separately deal with the oauth stuff).  Start by testing this base (this is mainly to verify you didn't change the default name/port/etc): (https://)yourserver.yourdomain.yourtld:7443/arcgis/sharing/rest (adjust as needed for your specific install until successfully reach portal's rest root) Then, for the portal item's metadata, append:  /content/items/abcdef0123456789/itemdata?f=json (where "abcdef0123456789" is the itemid of the portal item desired) Or for the actual webmap data itself, instead append:  /content/items/abcdef0123456789/data?f=json ... View more

I wanted to ping/refresh this topic, and provide some additional information (per my experience anyway), because this is STILL happening (as of 3.1.0), and is INCREDIBLY frustrating! Perhaps the key bit of info is that (for me, at least) this does not occur with file-based data - only occurs with data sourced from our EGDB (MSSQL-based). But for any data stored in the EGDB, the first edit to a field will result in the "cursor moved back before first character typed" behavior - so that typing "123" results in "231", or typing "abc" results in "bca". Sometimes, subsequent edits to that same field (e.g. tab or click away, then come back) will not exhibit the behavior (ie, will work as expected, correctly), but repeat a second/third/etc time and bad behavior might return again.  (and this unpredicatability makes it even harder to try to find a "muscle memory" keystroke approach work-around) The field doesn't have to be null (though a null value ALSO exhibits problem) - attempting a first edit to an already-populated field as an "overwrite" will still do the cursor shuffle and "scramble" typing order as described. by OP.. Say a field contains pre-existing value "test", now single-click the field within attribute table, the entire field will highlight, but it's not yet in edit mode (indicated by bold outline and highlighted value inside), now type "abc" intending to overwrite/replace the entire value, and you'll get "bca". I suspect there's something about the timing of the first typed character "auto-entering" edit mode (and perhaps a database read for a row lock) that causes the cursor to reset.  The only known workarounds involve using a different activation sequence.. If you slowly single-click twice (not double-click*) the field to highlight it first, then explictly enter edit mode, then any pre-existing value should remain selected and you can overtype it without cursor-shuffle - this is the only "reasonable" work-around known. (*double-clicking isn't as suitable because ~50/50 chance it won't leave pre-existing value selected) 6 bad, 3 good, in this screen capture: ... View more

More FYI, in case it helps anyone else:  Esri Case #02650635 After some exploration and experimentation, the problem seems to be related to an upgrade of our EGDB to 10.8.1. It was found that all of the unpublishable "bad names" had a similar history:  Prior to the upgrade, another featureclass existed in another schema having the same name.  For example, if the good copy was:  database.Authoritative.Zoning, then there was also something like:  database.Temporary.Zoning.  So both same-named featureclasses were present during the upgrade, and subsequently appears to have led to some sort of internal "mix up" that caused trouble when resolving names. The "fix" is to simply remove the non-authoritative copy, this will resolve the "bad name" conflict, and the authoritative version will again become publishable.  (recreating a same-named featureclass in other schemas after the upgrade does not replicate the problem going forward - in only appears to occur if the same-name-different-schema situation existed during upgrade) ... View more

FYI, in case it helps anyone else:  was replicated by tech support, is being forwarded to developer group (don't know a bug# yet). ... View more

Another upgrade-duration report FYI:  ~4hrs.  (i.e., "several minutes" indeed) Agonizing details: About a month ago (~1 week before 10.8.1 release) had completed a brand-new/from-scratch AGE 10.7.1 on a reasonably respectable 4-core 16G RAM 2T HD WinSvr 2019 VM.  Fully operational, but still non-production and essentially "fresh"/"clean" - only has a couple "starter" users created, no content yet.  Decided to upgrade it to 10.8.1 prior to production. The Portal install sat with an empty "Status:" and zero progress bar for well over an hour, but Task Manager at least showed some minimal activity (which I'm guessing is a backup phase), so I just baby-sat it and waited. The first indication of "it's actually alive" didn't occur til after that (maybe 1.5hr in) when it finally started "doing things" and the progress bar jumped to >50% (ish) where it again sat for a while.  Roughly 30min later the progress bar jumps to >90% (ish) and you reach the "Status:  Removing files" phase - the progress bar is reset during this, and took another ~30min, but at least you can see "File:"names changing.  After that phase, it again resets back to "Status:" blank and zero progress bar, Task Manager shows 0 cpu usage and a static memory footprint for the installer process, so I begin thinking "uh-oh", but I continue to wait.  About 30min later get "Status: Copying new files" and progress bar gradually fills (~5min ish)) then stalls at 100% and sits for a bit (~10min ish).  Then "Status: Component registration" (~5min ish) then "Status: Copying new files" again - progress bar slowly increments maybe 3%/min, about ~30min ish total, many "File:"name updates during.  Then at ~95% progress bar you reach "Status:  Installing new services" (~5min ish), then "Status:  Configuring the service" (0% cpu during, ~5min ish), then again a brief empty "Status:" and zero progress bar (~5min ish), then, finally, thankfully...  "Portal for ArcGIS 10.8.1 has been successfully installed". ... View more

I had this problem too, and believe I have a solution. But first, I assume you've already checked that the help docs don't apply: Step 4: Load a topology to a parcel fabric—Help | ArcGIS Desktop  That is, you don't have any true undershoots do you?  You have valid polygons and lines, correct? If so, then this FAQ may offer the needed clue (wrt same start/end vertex): FAQ: What are possible reasons for line sequencing errors when converting a topology to parcel fabric?  So check those isolated polygons - are they covered by a SINGLE closed-loop line?  (OP said theirs was)  If so, then THAT is what the cryptic "line sequencing" error message is actually complaining about. To test, simply split that line at any non-end vertex so that the boundary is now composed of two line segments, then try loading again. ... View more