I've ran into a problem recently where using sdemon -o info -I users -i 5151 will return "There are no ArcSDE users logged in." even though we know there are people connected to the database. In happened on one server and we just got by using other methods of determining users. But now it's happened on a second server.
Only thing I can think of that's different in these cases is that because the data we're working in is broken down into small sets, we have a large number of data users on each ArcSDE instance. On the one server we have 40. The second server has 4 SDE instances each with 10 data users. We did this so that each set of data can remain separate (they can all have a feature class with the same name) but without having to have 40 SDE databases. The second server only recently was bumped up to 10 data users each and just started having this problem. Other SDE databases where we generally only have one data user have not had this problem yet.
Has anyone else seen this before? Do you think it has anything to do with the multiple data users? I've been looking at other ways to save on resources and licenses by running multiple smaller sets of data on one database. Such as installing the ArcSDE service as the data user and not as the sde user. Maybe doing that differently will help. Any suggestions there as well?
Are you using Direct Connect or application server connections? Have you restarted the server recently? Have you done a DELETE or TRUNCATE on the SDE.PROCESS_INFORMATION table? - V
No direct connections. Only through the ArcSDE service.
I don't think the servers have been restarted in a while. They're used 24/7 so I would have to schedule a time to do something like this.
I haven't done anything to the PROCESS_INFORMATION table... But there are others who do maintenance on the databases who may possibly have. But I don't expect that they would have any reason to.
I generally get a different error if the database has been bounced, but 'giomgr' start will truncate the process information table, so if a manual service start was made against the wrong database instance, then this would explain it... - V
