Issue Details (XML | Word | Printable)

Key: CORE-3938
Type: New Feature New Feature
Status: Closed Closed
Resolution: Duplicate
Priority: Trivial Trivial
Assignee: Unassigned
Reporter: Arioch
Votes: 2
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Provide SQL mechansim to determine the client version of an Attachment

Created: 27/Sep/12 06:17 AM   Updated: Friday 08:04 AM
Component/s: Engine
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
Duplicate
 

Planning Status: Unspecified


 Description  « Hide
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.

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Simonov Denis added a comment - 27/Sep/12 07:34 AM
This is duplicate CORE-2780. But through RDB$GET_CONTEXT ('SYSTEM'...) too it would be quite good

Vlad Khorsun added a comment - 27/Sep/12 08:08 AM
The only way for server to know client version is that client say it to server.
But we can't modify old clients.
So, (one of) *practical* solution for you is to get client version in application and put it to the some user-level contex variable right after attach.

Arioch added a comment - 27/Sep/12 09:28 AM - edited
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
that means there is to be way for application to get it by pure SQL. The loop closed.
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. 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.

Sean Leyne added a comment - 27/Sep/12 04:01 PM
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.

Sean Leyne added a comment - 27/Sep/12 04:03 PM
Updated the subject/summary to better reflect the request

Arioch added a comment - 28/Sep/12 06:07 AM
1) If you want to move Oracle and make a caste of dedicated FB admins on salary, then yes.
If you want to have ubiquitous server "below eveyr hood" then it has its value.
Interbase was regularly presented as "install and forget", the database that can work well even without admins.
I think that is one of its primary assets, way more powerful than SQLite and almost as easy.
I think

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

Vlad Khorsun added a comment - 28/Sep/12 08:11 AM
Dmitry,

> FB-targeted access libraries have methods for it, but generic any-server libraries usually do not.
what is "generic any-server libraries" ???

> Personally i think explicit charset encodings are to be mandatory. Abitlity for clients to report their IDs can be mandatory too.
It could be done but it will not help you to identify old client. Also it will disable that old clients, do you really want it ?

> the very idea of this is to no more require special FB-only db libraries.
i don't understand you

> if client libraries themselves would issue such request, then that might be practical
This is how it works currently. And i see no another way.


I think you should discuss your request at fb-devel (or at sql.ru, if you wish) - it is not productive to do it here

Arioch added a comment - 28/Sep/12 12:29 PM
>what is "generic any-server libraries" ?
server-agnostic maybe better term.

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
it would.
If there is not data available - the nthe client is either broken or old, in both cases it is to be updated.
Surely it would not helpt to tell slightly-old client from very-old, but it would differ old from recent

> the very idea of this is to no more require special
I want to check fbclient.dll/gds32.dll version (and name if possible) using only - for example - dbXpress stock client. If it is too old, program would give user an error and halt, instead of potentially buggy behavior. I can use FB-specific components there and move server-specific checks into pluggable BPLs, but it would be more plain and uniform just to use main db connection library used by rest of application.

> This is how it works currently
Well, it can be done on wire protocol level or as explicit sql Set$Context command. That si the difference.
Maybe that is almost done, dunno, i failed to find details on resolution of CORE-2780 mentioned

Dmitry Yemanov added a comment - 07/Oct/12 12:07 PM
Shouldn't we close this ticket in favor of CORE-2780?

Simonov Denis added a comment - 07/Oct/12 04:31 PM
And that about implementation for RDB$GET_CONTEXT ('SYSTEM'...)?