nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Edits will not synchronize

TeresaSmithson2

Replication: One way parent-child with archiving
Parent Database: ArcGIS 10.1 SDE geodatabase on SQL Express on a dedicated server
Child Database: File geodatabase on network server

Feature class structure (simplified):
   Feature class of buildings - contains attribute for building number and polygons
   Feature class for building data - featureless (no geometry) attribute table containing all of the information regarding the building.
   Feature classes for other information - featureless attribute tables for plumbing, electrical, etc.
The "featureless" feature classes are not "tables", they are feature classes. I found the search ability to be more robust this way, but I also had synchronizing problems when this data was just tables.

Relationships: all of the various tables are linked via the building number or other common attributes between tables (e.g. building data has a code for plumbing that links to the plumbing table. Many of the links become circular, which works well for complete coverage of the data.

Problem:
If I edit any of the cells in the buildings feature class, the changes will synchronize. If I edit any of the cells in the featureless feature classes (data only attribute tables), none of the changes will synchronize. Is there something in the way that the tables or database is setup that would cause this problem. It's a good thing I have short hair - harder to pull out:-)

Any suggestion is wlcome, I have tried even things that seemed silly; all to no avail, but I am something of a newbie to this stuff.
Teresa

Vind meer berichten getagd met

Accepted answers

All comments

Anonymous User

That does surprise me. I'm sorry that didn't help. The last step I would try is setting up some small testing replicas, and figuring out exactly what does and doesn't work. I will be interested to learn the solution, when you find it!

TeresaSmithson2

Good morning! It may be your first rodeo, but you have discovered the truth about GIS: it stands for "Professional Troubleshooting!"

I have something for you to try: replicas hate invalid geometry. The introduction of invalid geometry will fail a replica. I suspect this is what you're experiencing. To find out...

Open an mxd, and add the parent data. Start an editing session. From your editing toolbar, click the Editor drop-down, and click Validate Features. It will likely pick up all the features in your "featureless feature classes," and tell you they're invalid. This would explain the failure; an invalid geometry introduced after the replica is created will fail the replication process.

The way I get around it: fix the invalid geometry, or recreate the replica and allow the invalid geometry to persist. In your case, the actual design is creating the invalid geometry, so you would need to either rebuild every time you synch, or switch over to geodatabase tables, and hit the forums for a solution to the search/table fail issues you described.

I hope that helps!

Hi Marianne,
I have eight tables that are data only; all but one returned valid. I am going to look into why that one table would be different from the other 7 since they were all done the same way at the same time. But I don't think this is the result you expected.

Appreciate your help.

Anonymous User

Good morning! It may be your first rodeo, but you have discovered the truth about GIS: it stands for "Professional Troubleshooting!"

I have something for you to try: replicas hate invalid geometry. The introduction of invalid geometry will fail a replica. I suspect this is what you're experiencing. To find out...

Open an mxd, and add the parent data. Start an editing session. From your editing toolbar, click the Editor drop-down, and click Validate Features. It will likely pick up all the features in your "featureless feature classes," and tell you they're invalid. This would explain the failure; an invalid geometry introduced after the replica is created will fail the replication process.

The way I get around it: fix the invalid geometry, or recreate the replica and allow the invalid geometry to persist. In your case, the actual design is creating the invalid geometry, so you would need to either rebuild every time you synch, or switch over to geodatabase tables, and hit the forums for a solution to the search/table fail issues you described.

I hope that helps!

TeresaSmithson2

Hi Joe,
I appreciate your responses. I am certain that this should be doable and that the problem is with my setup, I am just stuck as to what the problem is. As stated, when I was just using tables the replication would fail. I sent the files to ESRI and we worked over a period of several weeks trying to figure out why - to no avail. That is when I switched to using the data in feature classes instead and found that I, and more importantly the users, really like the increased search function using Find so I have stuck with this design, but still cannot get the edits in the tables to replicate.

I don't know if it is a product of our strange server configuration (as stated the parent is on a stand alone not accessible to anyone else except the 2 person GIS team and IT that has no GIS experience) or with the remote servers on a different network from the parent, or if it an indication of a problem with my database structure.

I am new to this game and this really is my first big rodeo. Unfortunately, I am also extremely isolated in Afghanistan and do not have access to many resources or other GIS peers - therefore I am posting on this forum. I will take a copy of the database home with me the end of this month and see if my graduate professor can find the problem. If it works in another environment, then I know the problem is our server setup. Maybe I'll just let it go and continue to just extract new databases to the user servers on a weekly basis and leave at that, but it drives me crazy when something doesn't work right!

Again, thanks for your feedback.

JoeBorgione

The tables were a major problem. I spent hours and hours with ESRI because the tables would not replicate to the remote servers. I also did not like the tables for the lack of search functionality. I hear that tables are just like feature classes, yet you can not access them with the Find tool. I am working in a transitory environment with trade people accessing table without the benefit of a designed user interface - everything is temporary, yet we have to keep track of over 100,000 assets including air conditioning units that move daily and are associated with the buildings. So not being able to use Find to search tables, and then identify and link to the building was a major issue.

So back to datasets. Everything i read placed an emphasis on datasets. Are you saying that you find a problem with them for replication? I could easily re-structure without them.

I replicate SDE tables to standalone File GDBs almost every day, so it's hard saying what the issue is. But I use SQl Server 2008 r2...

As far as feature datasets go, I'm saying they can create problems in SDE databases.

TeresaSmithson2

The tables were a major problem. I spent hours and hours with ESRI because the tables would not replicate to the remote servers. I also did not like the tables for the lack of search functionality. I hear that tables are just like feature classes, yet you can not access them with the Find tool. I am working in a transitory environment with trade people accessing table without the benefit of a designed user interface - everything is temporary, yet we have to keep track of over 100,000 assets including air conditioning units that move daily and are associated with the buildings. So not being able to use Find to search tables, and then identify and link to the building was a major issue.

So back to datasets. Everything i read placed an emphasis on datasets. Are you saying that you find a problem with them for replication? I could easily re-structure without them.

JoeBorgione

To be more specific, I created a new feature class in the SDE database, in the same dataset as the buildings. I then loaded the table with data from Excel and created a relationship between the new feature class and the building feature class that has geometry,
Hope that helps.

Using a feature dataset in SDE could be the root of your problems. I've been been able to replicate through a feature dataset, but I prefer not to.

Also, and please don't take offense, but I fail to see the reasoning in a feature-less feature class. You should simply use a table to store your related data. That may be part of the problem too.

TeresaSmithson2

To be more specific, I created a new feature class in the SDE database, in the same dataset as the buildings. I then loaded the table with data from Excel and created a relationship between the new feature class and the building feature class that has geometry,
Hope that helps.

TeresaSmithson2

It is a feature class but has no geometry associated with it. The attribute table is loaded with data from the excel spreadsheet.

Anonymous User

What's a "featureless feature class?" You explicitly state it is not a gdb table--what is it, or how did you create it?

TeresaSmithson2

Is it a "full model" or "simple model" replica?

It's a Full model, using advanced to include everything.

Anonymous User

Is it a "full model" or "simple model" replica?

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.