Skip to content
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

Closed
firebird-automations opened this issue Sep 27, 2012 · 15 comments

Comments

@firebird-automations
Copy link
Collaborator

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @sim1984

This is duplicate CORE2780. But through RDB$GET_CONTEXT ('SYSTEM'...) too it would be quite good

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

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.

@firebird-automations
Copy link
Collaborator Author

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
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.

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

priority: Major [ 3 ] => Trivial [ 5 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Updated the subject/summary to better reflect the request

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

summary: getting client version by pure SQL => Provide SQL mechansim to determine the client version of an Attachment

@firebird-automations
Copy link
Collaborator Author

Commented by: Arioch (arioch)

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

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

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 http://sql.ru, if you wish) - it is not productive to do it here

@firebird-automations
Copy link
Collaborator Author

Commented by: Arioch (arioch)

>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 CORE2780 mentioned

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Shouldn't we close this ticket in favor of CORE2780?

@firebird-automations
Copy link
Collaborator Author

Commented by: @sim1984

And that about implementation for RDB$GET_CONTEXT ('SYSTEM'...)?

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue duplicates CORE2780 [ CORE2780 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Duplicate [ 3 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant