Latest Contributions by AyanPalit

@NickKoopman  Switching to branch versioning should have clear drivers and be a well-thought out process (plan, design, test, implement). During planning, revisit the architecture and stated database setup. Some key considerations: Organization size and GIS data volume Purpose: What workflows will your data support User types: Office GIS analysts, mobile workers, public users, decision-makers — each has different performance and access needs. Data update frequency: Is it real-time, daily batch, or occasional? Performance: acceptable performance criteria System Integration Security and Access Control  As stated by @DavidSolari branch versioned geodatabase is more efficient. Due to this many organizations have collapsed the data architecture layers. Small organizations use a single branch versioned geodatabase to support Editing, Viewing and Field Work. Since branch versioned editing is done through feature services, the same database can be use for viewing through other map services. Field work can be supported using Feature Sync through Feature Services. You may not need the traditional geodatabase replication in a future state with slimmer data architecture. Consider these options, along with your organizations unique requirements to come up with a design that works well.  ... View more

@ElsitMandal1 Thanks for posting the screenshot; this helps. Suggest reviewing the LRS Locks table and correlate with the documentation. If there's an edit on the shared centerline, the LRS Locks table will show locks on both Routes. This is expected behavior. If only event on North south route is edited and has an event lock, with no locks on the route itself.  Then the East west route (with shared centerline) should not have a lock.  Try releasing the event lock and check if that resolves the issue.  Reference: Conflict prevention > Conflict prevention during centerline editing ... View more