Latest Contributions by BrendanCarroll

‎08-13-2019

Pro is just the worst! How they put it out in the market place is beyond me. It crashes all the time, basic features don't work and simple functions take forever. What's even more alarming is that it's not getting any better. Who has their hand on the steering wheel at ESRI? I heard even Jack was bashing it. Is it me or does it seem like they're not pushing adoption like they used to? Perhaps the sinking feeling is setting in. Look at all these crappy reviews and horror stories. What now, folks? I've wasted so much time and have nothing to show for it. Sure they've thrown some 3D bells and whistles into the mix but totally at the expense of reliability, basic functionality and performance. It's ESRI's Vista moment in the sun.

‎05-08-2019

Just to be clear this is an Azure PaaS PostgresSQL offering

‎05-08-2019

Yes the ArcPro box is on the same VNET as the Azure hosted PostgresSQL DB. All of the below are in compliance. Microsoft Azure Database for PostgreSQL—Versions 9.5.7, 9.6.2, and 10.3 ArcGIS connections to Microsoft Azure must originate from machines within Microsoft Azure. For best performance, connections should originate from machines within the same Azure region. Microsoft Azure Database for PostgreSQL is not supported in the Microsoft Azure Government cloud environment. Azure VM: Windows (Windows Server 2019 Datacenter) Standard B8ms (8 vcpus, 32 GB memory) East US 2 DB: PostgresSQL Version 10 East US 2 I'm running 3.2 with Enterprise 10.7 against Azure PostgresSQL 10 on the default 4 core instance. I have all the latest 10.7 Enterprise service packs as of this writing and the performance of all GP functions is unbearable. Copy paste of simple filegb model to Azure - 20Mins. Register as versioned - 5 mins. etc...

‎05-06-2019

Yeah I've seen and read a bunch of those threads. So i gotta ask, when does performance become the priority and goofy little bells and whistles get put on hold?

‎05-06-2019

it's unusable most times. not just rendering maps but gp ops are total dead dogs

‎01-19-2017

Bmp, Bmp

‎11-09-2016

We have a custom .Net Runtime client that leverages ArcGIS Server synchronization -check out, work disconnected, check in, the whole bit. Everything works fine if the checkout work areas are smaller. Sometimes, though, users need to checkout large work areas and that's where we run into file transfer size limits when pushing down to the client. It seems there's a 2GB limit using the SDK provided ArcGISHttpClient, which by all accounts is probably just a wrapper around the standard HTTP .Net client. After poking around a bit and looking at the SQLite DB produced by the out of the box ArcGIS Server checkout/sync routine, it appears there's a whole lot of wasted page space in the DB and running a simple VACUM on the SQLite DB could cut sizes in half. Is there a reason the checkout routine doesn't do this as the very last step in the creation pipeline?

‎01-29-2016

I'm getting the same error with the latest 1.4 API. I have compiled to x64 and it runs just fine in development in on my VS2013 x64. When I deploy the output to my host x64 or Windows Server 2012 box it won't run at all. I'm using the exact structure as in the sample. 1>------ Rebuild All started: Project: AVL, Configuration: Debug x64 ------ 1> 4 File(s) copied 1> 2 File(s) copied 1> AVL -> C:\temp\CityTrackerNav\CityDPW_NavmanTracker\bin64\AVLTracker.exe ========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ========== Esri.FileGDBAPI.dll version 1.4.0.183, VS2013 Update 5, Target framework 4.5.1 Error Log: Quartz.SchedulerException: Job threw an unhandled exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Esri.FileGDBAPI.dll' or one of its dependencies. The specified module could not be found. at SnowBlower.SnowJob.Execute(IJobExecutionContext context) at Quartz.Core.JobRunShell.Run() in c:\Program Files (x86)\Jenkins\workspace\Quartz.NET\src\Quartz\Core\JobRunShell.cs:line 187 --- End of inner exception stack trace --- [See nested exception: System.IO.FileNotFoundException: Could not load file or assembly 'Esri.FileGDBAPI.dll' or one of its dependencies. The specified module could not be found. File name: 'Esri.FileGDBAPI.dll' Thx in advance! -BC

Online Status	Offline
Date Last Visited	‎11-11-2020 02:24 AM

My Ideas

Latest Contributions by BrendanCarroll

Re: ArcGIS Pro 2.3.2 Crash and Fail

Re: Arcpro soooo slow my grandmother out performs it

Re: Arcpro soooo slow my grandmother out performs it

Re: Arcpro soooo slow my grandmother out performs it

Arcpro soooo slow my grandmother out performs it

Re: sync sqlite db size

sync sqlite db size

Re: Could not load assembly "Esri.FileGDBAPI.dll"

Re: Arcpro soooo slow my grandmother out performs ...

Arcpro soooo slow my grandmother out performs it