New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide SQL mechansim to determine the client version of an Attachment [CORE3938] #4271
Comments
Commented by: @hvlad The only way for server to know client version is that client say it to server. |
Commented by: Arioch (arioch) isn't wire protocol extensible, xml-like ? anyway, FB3.0 is major upgrade and wire protocol might be revised too. Personally i think explicit charset encodings are to be mandatory. Abitlity for clients to report their IDs can be mandatory too. > is to get client version in application if client libraries themselves would issue such request, then that might be practical. But it seems to be over-engineering. Also end-user applications are known for poorly following guidelines. You can not rely on end-user application to provide server info to server. |
Commented by: Sean Leyne (seanleyne) It seems that you want Firebird to implement something that would not be required where application install packages and/or network admins had 2 brain cells. Not a priority as far as I can tell. |
Modified by: Sean Leyne (seanleyne)priority: Major [ 3 ] => Trivial [ 5 ] |
Commented by: Sean Leyne (seanleyne) Updated the subject/summary to better reflect the request |
Modified by: Sean Leyne (seanleyne)summary: getting client version by pure SQL => Provide SQL mechansim to determine the client version of an Attachment |
Commented by: Arioch (arioch) 1) If you want to move Oracle and make a caste of dedicated FB admins on salary, then yes. 2) Alas there is also time constraint. As this would require client-engine interaction change (extending wire protocol or client-issued SQL statement after connect) it can probably only be made before 3.0 release or postponed to some indefinite future |
Commented by: @hvlad Dmitry, > FB-targeted access libraries have methods for it, but generic any-server libraries usually do not. > Personally i think explicit charset encodings are to be mandatory. Abitlity for clients to report their IDs can be mandatory too. > the very idea of this is to no more require special FB-only db libraries. > if client libraries themselves would issue such request, then that might be practical I think you should discuss your request at fb-devel (or at http://sql.ru, if you wish) - it is not productive to do it here |
Commented by: Arioch (arioch) >what is "generic any-server libraries" ? JDBC, ADO, BDE, dbExpress - any library abstracting from details of certain RDBS vendor > It could be done but it will not help you to identify old client > the very idea of this is to no more require special > This is how it works currently |
Commented by: @sim1984 And that about implementation for RDB$GET_CONTEXT ('SYSTEM'...)? |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: Arioch (arioch)
Duplicates CORE2780
Votes: 2
To provide easy upgrade of network application when sysadmins skills are lacking, it would be nice for every client application be able to determine and report its client library used (to avoid using old client libraries).
FB-targeted access libraries have methods for it, but generic any-server libraries usually do not.
I wish that either MON$ATTACHMENTS or RDB$GetContext('SYSTEM',...) be extended to allow report of name and version of client library used for current connection.
This would also ask for extending wire protocol to provide updated client libraries report their ids.
The text was updated successfully, but these errors were encountered: