Hosted Publishing Fails and Diverges From the Authoritative Geodatabase

The analysis made a defensible-sounding choice with the wrong consequence. Publishing as a hosted feature layer means the portal copies the data out of SQL Server and into the managed ArcGIS Data Store relational store. For 14 million features that is a bulk extract, transfer, schema creation, and load - hours of work, a large transaction on the source, and a publish request that must stay alive the entire time. The 92% timeout is the publish operation, not a data problem, and the 180 GB transaction log is the copy reading the source within one long transaction.

The right pattern is a referenced feature layer from the already-registered database data store:

• The enterprise geodatabase is already registered as a database data store (registered, not managed), which is precisely the configuration that allows publishing by reference.
• Publish with Feature Access enabled but do not choose to copy the data; the service then reads the authoritative table directly through the registered connection.
• There is no duplication, no divergence, and edits made nightly via the geodatabase are immediately visible.

This also retires the divergence symptom, which is the more serious problem: a stale copy of a water network is an operational hazard, not a performance annoyance. The duplicate layer published last year should be deleted after confirming which items and maps depend on it; removing a feature layer that an app still calls produces its own outage.

A caveat worth stating: a referenced layer puts production query load on SQL Server. Test the 250-user read pattern, verify spatial indexes and statistics on the asset tables, and set max record count and feature limits on the service.

Offline editing is not a property of the layer alone; it is a chain of requirements that must all hold:

1. Sync capability on the service. Feature Access must be enabled and the Sync capability turned on at publish time. If it was not enabled, the layer must be republished (or the capability enabled and the service restarted) before any offline client can register a replica.
2. Versioning that supports sync. Referenced feature layers with sync require the source to be branch versioned for a modern editing workflow; traditional versioning with archiving also supports replica-based sync but has reconciliation overhead and conflict behavior that field crews handle poorly. Given "registered as versioned" in the current state, confirm which type it is - this is the requirement most likely to be missing.
3. Editing privileges end to end. The field users need a role with edit privileges, the layer must allow editing, and the database account in the registered connection must have write privileges on the table.
4. Attachments and metadata. If crews capture photos, attachments must be enabled on the layer before publishing; enabling afterwards loses structure.

Verification, in order: check the service's capabilities in the REST endpoint (Sync listed), open the layer in a browser as a field user, create one test replica from Field Maps or ArcGIS Pro, make an edit on a mobile device while offline, sync, and confirm the edit appears in the geodatabase and in SQL Server. Then test the conflict path by editing the same feature in two places. Do not declare success on a single happy-path sync; the failure mode that embeds bad data is a silent conflict resolution.

The fact that it validates for one person and not another is the clue: the data store item stores a connection, and validation runs as the connecting user. Different credentials therefore produce different validation outcomes against the same database.

What to check:

• Who the connection user is. For a database data store registration, the connecting user generally must be the geodatabase administrator (sde or dbo depending on the SQL Server setup) or hold equivalent privileges. A regular data owner can read the data but cannot satisfy registration prerequisites, which is exactly the "privileges error" seen here.
• Whether the user is a user-schema user. A schema-owner connection behaves differently from the geodatabase administrator and is a common source of registration failures.
• Geodatabase version compatibility. The geodatabase must be at a version supported by the ArcGIS Server release; an unupgraded enterprise geodatabase after a server upgrade will validate inconsistently.
• Instance and network reachability. The instance name and port must be reachable from every machine in the hosting server site, not just the one that succeeded.
• Database state. Read-only replicas, databases in recovery, and machine-name change side effects all break validation.

Recommendation: standardize on one documented registration account (the geodatabase administrator) with credentials stored by the portal, and stop letting individuals register data stores ad hoc. The successful validation by the analyst is a false positive that hides a real configuration defect - and it will be discovered at the worst possible moment.