Latest Contributions by MikeWinsor

Yeah, I tried doing that, but it still locked up, and it would lock up in random places (sometimes when we were querying features, other times when we moved the map around). We upgraded to 10.2.7 and .NET 4.6.1 and everything seems to be OK now. ... View more

So, it looks as though 10.2.7 has fixed whatever was causing this problem.   ... View more

Thanks, we'll do just that and see how it goes. ... View more

Thank you, I've emailed Rex. Regarding support, we have not deployed this into production, and we are in dev for this phase. However, we have a rather substantial customer base who access the applications through Citrix and being able to run the applications through it is mandatory for us. ... View more

No, I'm afraid I don't. Also, our customers are not guaranteed to have access to one either. ... View more

I've gone ahead and created a sample to illustrate the error.  It is attached to this comment. To replicate the error: Draw a small line at the default extent. Scale out to a much larger distance Draw another line. An error message about Error code 500 addFeature failing should appear.  If it does not, try zooming out further. ... View more

Hey Mike, Thanks for getting back to me. I'm out of the office until Tuesday, so I won't be able to look into this. I did open a support request about this issue and sent them a copy of my geo processing model (and a sample project that illustrates the issue). I could send it to you on Tuesday. More eyes on the problem might yield a quicker analysis and all that. Regardless, it seems like this may be a bug in the ArcMap geoprocessing package generation, at least from my conversation with support. I did get other geoprocessing models to nearly work (By nearly I mean the code executed and returned different errors that were my own fault for sending the wrong type of data as parameters). And some geoprocessors like Create Route + Make Route Event Layer worked perfectly (except that my measure values were off - but Thad Tilton helped me get around that). Anyway, like I said, I'm not in the office, so I won't be able to try those steps. But I'll give it a shot on Tuesday. At this point my company has decided to forego building the map data with the Runtime and use a separate ArcObjects process to do that. That said, I would like to help solve this particular issue, so I'll definitely devote some resources to doing so. Just as an aside, I did try and build a geoprocessing package with only the Make Feature Layer tool inside the model, and that error came up then as well, not only that, but trying it with the Make Table View by itself tool also resulted in the same error. When I tried the Make Route Event Layer tool on its own, that error didn't pop up, but I did get an error about incorrect feature class type (my fault as I mentioned above). When I looked at the service web page directly through a browser I noticed something strange. Normally when I go to my URL for the processing service, I can see the task(s) inside the package listed on the page. When I had the Make Feature/Table View tools on their own in the package, nothing showed up at all, and with Make Route Event layer on its own, the task was listed on the page. Maybe that indicates something? ... View more

Hey Thad, Thanks for that, I already figured out that the QueryTask will send back the M values. Unfortunately, after I was able to do all that, I ran into an issue with the geoprocessing model/package that I had built to route my non spatial event data. Just can't win sometimes eh? Anyway, I posted about the issue here Getting exception: " Error code '400' : 'Unable to complete operation.'\Error executing tool.: ERROR 000816: The tool is… Thanks for all your help again, it's much appreciated. ... View more

We've applied the patch to ArcMap 10.3.1. I built a brand new model from scratch using the same tools and exported it as a runtime geoprocessing package. Unfortunately, the patch did not work. I am still receiving the same exception. I have opened a case with Esri support about this. Hopefully they can help resolve this quickly as my time is running short. In the meantime, I'll tell you what I'm doing (I've explained this in other posts, but I'll repeat it here). And maybe you can give me some insight into a better way: Our old applications use ArcObjects. We want to move to .NET with x64 support, so we're using the runtime SDK to build a new mapping component. The previous component would create an MXD document, and populate it with layers. Some of these layers were Route Event Layers that used SDE connections to the client SQL servers (these were updated on the fly when the connection info changed) to dynamically retrieve data and route it along a central line using routing measurements supplied by our clients. This allows our clients a great deal of flexibility when manipulating their data. In our upgrade, I've managed to generate the centerline (plus some ancillary layers that don't apply here) by using a ServiceFeatureTable (and now direct JSON calls because the ServiceFeatureTable refuses to accept custom Measure values). This part works very well, and it generates fast. Now it is time to add these dynamic layers (facilities layers). We have the facility data, which only contains a start and end point. Using this we need to overlay the facility feature on top of the central line on the map. Unfortunately, I cannot use SDE connections to the tables (or at least, it's never worked for me) using a map package and the LocalFeatureService. So, I built a GeoProcessing package to do the job. Here's what I do: Get feature data from the central line that fits within our view extent. I managed to get the central line data back with M values by using a QueryTask (hopefully it's correct, I can't tell at this point). Load data from the SQL table that matches the feature data by a specific ID value. Convert that data to a Feature Set Execute the geoprocessing package with the 2 feature sets as parameters. The model will take the central line feature set parameter data, and convert it to an in memory feature layer via the Make Feature Layer tool. The model will take the event feature set parameter data, and convert it to a Table View using the make Table View tool. The outputs from these two tools are then passed to the Make Route Event Layer tool. The output from Make Route Event Layer tool is read by my application and an empty pre-existing layer will be populated with the routed features from the make Route Event Layer tool. So, as you can see, it's a pretty complex workflow here. Any suggestions on how I could simplify this (locally, we're not ready to jump on ArcServer yet as our clients may freak out over that)? Since ArcMap refuses to dump out a geo processing model that works for me, I'm hoping there's a potential solution here that I've overlooked or something. ... View more

I'll attempt to get this patch applied when our system administrator comes in. ... View more

And just like that, what was working is now giving me more issues... So as I mentioned before, I'm using the MakeRouteEventLayer to add non-spatial data that's routed along the centerline.  This works great in ArcMap.  However, from my code... not so much. So here's what I had prior to correcting the M value issue: Query the service feature table for the centerline, and retrive all the IDs and geometry within an Envelope. Retrieve the event data from the SQL server linked by the IDs returned from the aforementioned query Convert this data into a feature set for passing to the geoprocessor. Execute my geoprocessor, passing in the centerline data, and the event data as parameters (Centerline is a Feature Set parameter, and the event data is a record set parameter). Get a feature set returned from the geo processor Add the features as graphics (not a fan of that, I'm going to try and change this to a feature service table). And prior to adding the M values, this all worked swimmingly (albeit, horrendously slow) except that the measures were off. Now that I have my M values, I can't really use the first step any more because the M values are not returned to the client (as you mentioned). Ideally, what I'd really like to do is reference the layer directly in the geoprocessing package; that'd circumvent the issue entirely. Unfortunately, I have no idea how to do that, or even if it's possible? Am I able to reference a layer (that exists in my map package) in the geo processor package without that package needing to contain a snapshot of the layer data? This is because we are working with live data here, and snap shotting just won't cut it unfortunately. Or am I wrong in thinking that the packages take snap shots of data? ... View more