I remember this post from Georg Schäfer, but I don't remember if it was
there:

===
Another problem is that the API-Funktion that delivers
the actual users attached on a database doesn't work
correct on huge connection numbers.
The usernames are returned in a limited buffer, and
therefore you can't see all of them when the number of
users exceeds some certain limit depending on the
length of the names.
We often have more than 100 connections to one
database, but we can only see 83 of them ...
===

It makes sense. If you were to request ONLY the item isc_dpb_number_of_users
through isc_database_info(), it means a list of users has to be fitted in a
buffer. Doing some assumptions:

- Each userid is 8 characters length.
- There's a fixed 1024 bytes buffer at some place.
- To return a userid, the engine takes the raw name without C's null
terminator and prepends a length indicator that's only a byte. But it pass
it to another function that wraps the whole content as follows:
isc_dpb_number_of_users || 2 bytes for the length
|| byte length indicator || userid's name
I know it sounds stupid to have two length indicators, the first including
the second so it's always one unit more, but this is the way the API works
and this is the result string the the application gets filled by the engine.
For each user, 4 bytes of overhead. If you want to nitpick, every item
stream is finished by isc_info_end, so you are left with 1023 bytes.

1023 / 12 = 85.25
Georg said 83. One issue is that you not necessarily ask for the users item
alone, you can include other items in the same API call, that use space from
the same buffer. This compensates for user names not being necessarily 8
characters.

The core engine doesn't have a limitation here. Jason Wharton told me two
years ago that using a local connection retrieves always all users. So,
taking aside the possibility that there are some multiser issues, there
should be a hardcoded buffer in the remote interface.

The bug had a healthy life for about 8 years, but died tonight. RIP. No more
1024 bytes absurd limitation for retrieving the list of users. Just pass a
larger buffer from your client app to isc_database_info().
:-)

The person writing the code assumed that 1024 would be big enough for any
real usage... and there are several places in the engine that assume we are
happy with fixed limits.

Many thanks to Georg for his quantitative observation.

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing