Latest Contributions by JoeBorgione

‎10-12-2012

Creating a summary table is pretty easy within a personal or file geodatabase as well as setting up the relationship in ArcMap. Glad it worked for you!

‎10-12-2012

I have a base set of data, Street Centerlines. I have a historical table that has multiple entries per street These two are related by a unique field. In the Historical table I have a Year field What I want to do is join the two and populate a Year Field in the Street Centerlines...BUT i need the most recent year from the Historical Table. I can do this with a join but I am sometimes getting the Older Year and Sometimes getting the Newest Year. Where a particular entry in the historical table may match to Street "4534" but have 3 records with 3 different years. Street Centerlines '4534' Historical Table '4534' 2002 '4534' 2005 '4534' 2010 How do I do this and make sure that I get the most recent year in all the recrods? That make sense? Thanks Nice problem to solve! The first step I would take is to create a summary table for the unique id and get the 'maximum' year for each id. You'll get a count of the record ids, along with the maximum (most recent) year In the second step, create a relation between the summary table and the historical data table based on the MaxYear attribute in the summary table and the Year attribute in the historical data. Select ALL the records in the summary table; then choose related tables. This selects just those records in your historical data table with the most recent (maximum) year, regardless of id. Write those selected records to it's own table; let's call it History2. Finally, you can then JOIN your current data to History2 via the unique ID. Give this a spin and see if it does the job for you...

‎10-10-2012

Well, at the risk of starting a flame war, your use of the phrase "feature class in a non-sde database" is what threw me. Any databse I've ever worked with outside of the GeoDataBase realm uses the term record....

‎10-10-2012

ArcGIS Desktop 10.1 does not support editing feature classes of a non-sde database. What does this mean? Are you saying that at 10.1 all personal and file based geodatabases are off limits? I hardly think so...

‎10-03-2012

Chicago PD would be the first place I'd look. That is a tall order; the thing about data and data analyses is sometimes you have to take what you can get; if it's by beats or what ever, you'll need to do some manipulation to get it into census tracks. Given that it's data about children, that makes it even tougher...

‎10-02-2012

Kevin- I checked the noaa aloha page and there's a contact link there. Hopefully they can tell you. All the best-

‎10-02-2012

Hey Joe: That's exactly what I did this morning. I was hoping there was a more efficient fix or that I was simply missing something. Your workaround was the fix. Scott Sometimes ineffeciency is effcient! I mean you can spend a lot of time trying figure something out or just go get the hammer and beat it into submission, right?!

‎10-02-2012

Can't tell you what's going on except that feature datasets and sde have never really gotten aong very well. May I suggest a work around? Create a new empty feature class of the same geometry and schema as the one that's giving you the heartburn. Using the simple data loader, load the heart burn features into the new feature class. Now for sure there is no versioning issues with the new feature class, right? See if that goes into your feature dataset...

‎09-21-2012

Certifiable yes; certified no... 😛 I use the versioned environment such that sde.default is the top of the heap, and the versions beneath it get edited. I can see how flipping the scenario would work as well; edit sde.default and 'push' the changes out to various versions, although I've never had the opportunity to try it that way. All the best-

‎09-21-2012

Greg- for me I've gone with the latter; it is the process in which a version is compared to to the version it was spawned from for conflicts. I hasten to use the terms parent and child, as I prefer to use them in discussing the distributed database model, or replication. In a simple versioned database, there is sde.default, and spawned from it is one version; lets call it version1. When reconciling, version1 is compared to sde.default. If sde.default has a feature that has been edited and version1 has the same feature edited, that's a conflict and you get to decide which edits you want to keep. Typically, I don't allow edits to be made directly to sde.default. You open up to conflicts if sde.default spawns several versions: lets say version1, version2 and version3. You reconcile (and post) the changes in version one to sde.default, and then later, you reconcile version2 to sde.default. If someone edited the same features in version2 that someone else edited in version1, you'll get a conflict. For that reason, I typically only have one 'edit' version that all my editors work on. I have a number of editors and used a version for each. That became an administrative nightmare in no time at all. One really nice thing about versions is you can use them to create scenarios; if you don't like what you see, get rid of it, and no one is the wiser... Hope this helps-

‎09-20-2012

Hey, ease up Scott; you might notice that Alexey has been around a while providing a number of useful posts. No need for the harsh sarcasm; perhaps you should check with the data vendor on how to use the product. Have a very nice day.

‎09-19-2012

Barry- just one of the many reasons why I don't like using feature datasets in a SDE database. They just don't play well together at a number of levels.... Glad you figured it out your problem though!

‎09-19-2012

I have been trying to add records to the attribute table. I can input the new records into several fields ok. I assumed that I just had to recalculate the geometry, however, I keep getting an error message: All calculated values are invalid and none of the rows have been updated. Can you walk me thru the correct process. Thanks. Let's get some nomenclature straightened out first: you add Values to fields. A record is a row of fields. In a feature attribute table, you must first add the feature (point, line or polygon) before you can populate the field values. Hope this helps-

‎09-18-2012

John- I made the (reg)edit and it seems to be working as promised on my NT machine....

‎09-14-2012

Hey guys check out the response that just rang in my email from the Ideas Guys @ ESRI (And thanks to Chris Fox for a quick reply!) Thank you for contributing on ArcGIS Ideas. We are happy to inform you that your idea, Set Classic Snapping as Default, has been implemented. For more information about the implementation of this idea, please refer to this Idea's Comments section. Regards, ArcGIS Ideas Team Follow the link and you'll see it can be done with a registry modification...

Online Status	Offline
Date Last Visited	‎05-19-2026 11:56 AM

My Ideas

Latest Contributions by JoeBorgione

Re: Join and HIstorical Data 1 - Many relationship

Re: Join and HIstorical Data 1 - Many relationship

Re: Error creating geodatabase: User, group, or role 'dbo' already exists

Re: Error creating geodatabase: User, group, or role 'dbo' already exists

Re: Data for Juvenile Index Crimes by Census Tract

Re: ALOHA compatible w/ 10.1?

Re: Problem Adding Feature Class to Topology

Re: Problem Adding Feature Class to Topology

Re: What exactly does 'reconcile' mean?

Re: What exactly does 'reconcile' mean?

Re: Turn Restrictions

Re: ArcSDE locking feature dataset

Re: Adding Records to existing attribute table

Re: change default to classic snapping

Re: change default to classic snapping

Topology in a Versioned GDB

Re: How do I edit metadata with Python?

Attribute Pane Properties

Re: Artificial Intelligence in GIS

Re: Data Scrubbing Addresses

Addressing

911 GIS