On 3/1/19 12:40 AM, Adriano dos Santos Fernandes wrote:
Grouped by user name of what connection pool already is configured for:
the user name to connect.
Certainly. Mapped user name has nothing to do with connection pool.
Why would anyone need the mapped user name instead of the already know
On 2019-02-28 20:57, Adriano dos Santos Fernandes wrote:
On 28/02/2019 16:54, Mark Rotteveel wrote:
The same can be asked for a lot of other information items that can be
obtained from isc_database_info. And the answer is invariably: because
it can be useful for an application or a driver itsel
On 28/02/2019 17:09, Dimitry Sibiryakov wrote:
> 28.02.2019 20:42, Adriano dos Santos Fernandes wrote:
>> Then the question: for what the client would need to known the mapped
>> user name?
>
> The simplest example: connection pool must grouped by user name
> because currently there is no way to
28.02.2019 20:42, Adriano dos Santos Fernandes wrote:
Then the question: for what the client would need to known the mapped
user name?
The simplest example: connection pool must grouped by user name because currently there
is no way to change current user of already established connection. (
On 28/02/2019 16:54, Mark Rotteveel wrote:
>
> The same can be asked for a lot of other information items that can be
> obtained from isc_database_info. And the answer is invariably: because
> it can be useful for an application or a driver itself to obtain that
> information.
>
Why it could be ne
On 2019-02-28 20:42, Adriano dos Santos Fernandes wrote:
On 28/02/2019 16:20, Mark Rotteveel wrote:
As far as I understand it, if you use the Firebird 3 mapping feature,
than you can remap the login and role of any user to an entirely
different user.
So, as far as I know, a client no longer kn
On 28/02/2019 16:20, Mark Rotteveel wrote:
>
> As far as I understand it, if you use the Firebird 3 mapping feature,
> than you can remap the login and role of any user to an entirely
> different user.
>
> So, as far as I know, a client no longer knows what the actual user
> is, even if it used use
On 28-2-2019 13:00, Alex Peshkoff via Firebird-devel wrote:
On 2/28/19 2:15 PM, Kovalenko Dmitry wrote:
Can you explain - what a problem with use of SQL to get that data?
Need start (and commit) implicit transaction.
For me - it is not good behavior of provider.
For RORC I can't say for sure
On 2/28/19 2:15 PM, Kovalenko Dmitry wrote:
Can you explain - what a problem with use of SQL to get that data?
Need start (and commit) implicit transaction.
For me - it is not good behavior of provider.
For RORC I can't say for sure that this is too bad behavior. But as a
minimum getInfo() r
> Can you explain - what a problem with use of SQL to get that data?
Need start (and commit) implicit transaction.
For me - it is not good behavior of provider.
Dmitry Kovalenko.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
No, you can have e.g. windows autentication
Regards,Karol Bieniaszewski
nullFirebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 2/28/19 1:46 PM, Adriano dos Santos Fernandes wrote:
On 28/02/2019 05:30, Kovalenko Dmitry wrote:
select current_user from rdb$database
Usage of similar queries is not good idea for connection provider.
It is problem to added new info-tags (current_user and, may be,
current_role) for isc_da
On 28/02/2019 05:30, Kovalenko Dmitry wrote:
>> select current_user from rdb$database
> Usage of similar queries is not good idea for connection provider.
>
> It is problem to added new info-tags (current_user and, may be,
> current_role) for isc_database_info in FB3.0.5?
>
> From my side I will ad
> select current_user from rdb$database
Usage of similar queries is not good idea for connection provider.
It is problem to added new info-tags (current_user and, may be,
current_role) for isc_database_info in FB3.0.5?
>From my side I will added the special support for these new tags into my
pro
14 matches
Mail list logo
