We've recently discovered the same behavior with SDE GDB's as well, which prevent other users from modifying the schema:
Add a SDE feature class to a new map and click the edit ribbon but don't edit anything.
Run
INSERT INTO @tblVariable
EXEC Master.dbo.sp_who2
SELECT v.*, t.TEXT
FROM @tblVariable v
INNER JOIN sys.sysprocesses sp ON sp.spid = v.SPID
CROSS APPLY sys.dm_exec_sql_text(sp.sql_handle) AS t
where DbName = 'GRSM_VEG_MAP'
ORDER BY HostName DESC, CPUTime DESC
and note how many transactions return from the user/host name that has this feature class open in Pro
Close the map (but not Pro)
Rerun the same SQL query
Note there are still transactions (same host/user) open associated with you doing nothing more than adding the FC to a new map.
From another host/user, in Cat view, right click on that feature class in SDE, attempt to add a new field (design fields). Fails...contact ESRI for TS....
Through 2 weeks now of isolating this, as we have many feature classes we can't update because of this ghost schema locking, we narrowed it down to:
If one user adds a GDB feature class to a Pro map on their machine, then closes the map, but the project remains open, other users on other machines cannot modify that feature class, which seems similar to the behavior you are seeing with the FGDB.
What we've discovered is, if we want to make a change to a feature class, EVERYONE has to shut Pro down, as we have no idea what maps in what projects have "touched" that feature class.
Of more interest, remember, the feature class is now no longer "touched" in a map, remember, we closed the map, saving and closing Pro fires more transactions associated with this host/user (in this specific database).
Close and restart pro, transaction locks are gone....
