Commented by: @dyemanov

Total length of input or output parameters is limited to 64K minus overhead. This is an API limitation.

Commented by: Vsevolod Migdisov (vmigdisov_gmail.com)

Thank you very much!
One more question. I'm busy with writing an Application Server based on Firebird. I hope that it will be useful for developers who writes business applications based on Firebird and want to concentrate on data model and business logic instead of end-user interface. But I extremely need in new Firebird Function - Unique client identification (something like GUID), which will be generated and stored on the Firebird Client side and delivered to the Firebird Server (during starting session, i.g) and can be used in SQL (like "USER", i.g.). Do I have any chance to get it? (I just don't know who I need to ask for).

Commented by: @dyemanov

RDB$SET_CONTEXT(USER_CONNECTION, <variable>, <value>) -- on client
RDB$GET_CONTEXT(USER_CONNECTION, <variable>) -- on server

Commented by: Vsevolod Migdisov (vmigdisov_gmail.com)

Thank you very much again!
so I can do like this:

on client:
declare variable GUID integer;
GUID=RDB$GET_CONTEXT(USER_CONNECTION, 'GUID');
if(GUID is null)then
begin
GUID=gen_uuid();
RDB$SET_CONTEXT(USER_CONNECTION, 'GUID', GUID);
end

on server:
RDB$GET_CONTEXT(USER_CONNECTION, 'GUID');

excellent!
but where Firebird store this parameters?

Commented by: @dyemanov

In the server memory, of course. It's not accessible via system tables or alike.

Commented by: Vsevolod Migdisov (vmigdisov_gmail.com)

Then It can't help me. I need to have a constant variable which should be generated once and stored on Client and stay the same each connection.

Commented by: Vsevolod Migdisov (vmigdisov_gmail.com)

I already comprehended that it is not possible. Be course if you use embedded server than there is no place to keep GUID and if you will keep at the application folder then it can be moved to another computer.
Probably it's possible to get MAC address from the network interface and send it to a Firebird Server as unique station identification?

Commented by: Vsevolod Migdisov (vmigdisov_gmail.com)

на сервере: RDB$GET_CONTEXT('SYSTEM', 'NETWORK_MAC'); - например! вот было бы идеально! ведь MAC наверняка передаётся по TCP/IP (раз есть привязка сетевых устройств по MAC адресу) и достаточно это сделать для сервера!
я вам уже надоел? :(

Commented by: Vsevolod Migdisov (vmigdisov_gmail.com)

No chance?

Commented by: @dyemanov

Nope, I don't think it makes any practical sense.

Commented by: Vsevolod Migdisov (vmigdisov_gmail.com)

This is my letter to Firebird-developers which describe the practical sense^

Is it possible to add Variable 'CLIENT_MAC_ADDRESS' which returns MAC address of the client network interface throw which it connects to Firebird Server?
As I good understand MAC address should be delivered with TCP/IP (for ARP table in router or WiFi access grants e.g).
Something like rdb$get_context('SYSTEM', 'CLIENT_MAC_ADDRESS').

It is necessary to identify client station for:
1. Control connections to current database for the registered stations.
2. Deliver a certain number of updates to the client machine.

Commented by: @dyemanov

You've been answered in firebird-devel. I'd suggest you to put your arguments there instead of the tracker.

Commented by: Vsevolod Migdisov (vmigdisov_gmail.com)

They answer nothing because of I'm not a member and probably my letter was not moderated.
I'm just trying to make dialog with someone who can understand things what I'm trying to do.
My system is a child up to now, but about 1000 machines in 10 huge financial agents (Alfa Group, Alor +, KIT Finance etc) is using it at this moment for document flow and it is really necessary to control stations on the server side.
I just need a little bit help to make a free Firebird Business Suit for every programmer who use Firebird for document flow and accounting.

Commented by: Cosmin Apreutesei (cosmin_ap2)

Hope all that talk didn't overshadowed the "64K minus overhead stuff" :) This and all other size limits (like CORE755 which is rated minor??) are the most annoying limits of firebird, making me create a plethora of otherwise equal domains just so that firebird won't complain.

Btw, the 64K doesn't really say much, because in practice you can't use anything bigger than 4K with UTF8, since sooner or later you'll want to put at least 2-3 of those fields in a table or as sp parameters.

Then, if/when you do increase the limits, please allow indexes to span multiple pages so they can catch up with the changes.

Thanks.