|
|
|
|
|
|
|
|
|
|
| Re: auditing the version of the client [message #245630 is a reply to message #245584] |
Mon, 18 June 2007 04:32   |
aline
Messages: 92
Registered: February 2002
|
Member |
|
|
good!
so there is two solution!
What is the query to do that from inside?
If a client could know that, with a database trigger on connect, I could easily manage my problem.
And how activating sql*net to do that to?
Thk for ur help!
|
|
|
|
| Re: auditing the version of the client [message #245635 is a reply to message #245630] |
Mon, 18 June 2007 04:43 |
 |
Michel Cadot
Messages: 68686
Registered: March 2007
Location: Nanterre, France, http://...
|
Senior Member
Account Moderator |
|
|
This is not a query.
It can't be done from inside the server (afaik), so a logon trigger is useless.
To know from the client, this depends on your programmatic language.
What it yours (Pro*C, OCI, SQLJ, JDBC, OO4O, OLE DB...)?
Regards
Michel
[Updated on: Mon, 18 June 2007 04:44] Report message to a moderator |
|
|
|
|
|
|
|
| Re: auditing the version of the client [message #245676 is a reply to message #245635] |
Mon, 18 June 2007 07:33 |
aline
Messages: 92
Registered: February 2002
|
Member |
|
|
| Michel Cadot wrote on Mon, 18 June 2007 04:43 | This is not a query.
It can't be done from inside the server (afaik), so a logon trigger is useless.
|
I'm sure it could be.
Just an example:
| Quote: |
C:\Documents and Settings> sqlplus
SQL*Plus: Release 9.2.0.8.0 - Production on Mon Jun 18 14:29:55 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Enter user-name:
|
So I have the information here (eg: SQL*Plus: Release 9.2.0.8.0)
I just want to capture this information in a logon trigger!
|
|
|
|
|
|
| Re: auditing the version of the client [message #245714 is a reply to message #245685] |
Mon, 18 June 2007 10:57 |
ThomasG
Messages: 3212
Registered: April 2005
Location: Heilbronn, Germany
|
Senior Member |
|
|
A seach for "python oracle" has shown me at least 4 possible python->oracle modules that could be used.
If it's DCOracle2 you can maybe use the DCOracle2.version variable in your python code to get some client version information into a python variable.
When you then fire a
dbms_application_info.set_client_info('[your_version]')
after you connect from your client, that info can be queried over the client_info field in the v$sessions view on the server.
There is no unified way of querying the client, since it could even be possible that a client connects without any "normal" oracle client installed by using a java thin client, or a third party driver.
|
|
|
|
| Re: auditing the version of the client [message #245719 is a reply to message #245134] |
Mon, 18 June 2007 11:53 |
aline
Messages: 92
Registered: February 2002
|
Member |
|
|
thk for ur answer.
You have had understand very clearly my problem.
My problem is I have not the control of the client side! (If I had, I'll have unified all of my client and I'll have no reason to control that). So for me, the only way to know what is the version of my client is to work from the server side! If they are no way to do that, I'm afraid that I'll have no solution for my problem
|
|
|
|
|
|
|
|
| Re: auditing the version of the client [message #246325 is a reply to message #245134] |
Wed, 20 June 2007 11:20 |
aline
Messages: 92
Registered: February 2002
|
Member |
|
|
Hi,
Thank for your answer.
We are currently updating database version and client version or our system. We don't want to have 'to old' client to avoid different bug. So the only solution to be absolutely certain than there is no old client is an audit in the server side.
So now you know all my problematic!
|
|
|
|
|
|
| Re: auditing the version of the client [message #246335 is a reply to message #246333] |
Wed, 20 June 2007 11:40 |
DreamzZ
Messages: 1666
Registered: May 2007
Location: Dreamzland
|
Senior Member |
|
|
| Michel Cadot wrote on Wed, 20 June 2007 10:38 | Your problem is more organizational than technical.
If your upgrade/application needs a specific client then all clients must be upgraded.
If some are missing then you have an issue in your ugrade process.
Don't you know all your clients?
How do you upgrade their applications if you don't know them?
Regards
Michel
|
Make sence..
|
|
|
|
| Re: auditing the version of the client [message #246517 is a reply to message #246335] |
Thu, 21 June 2007 03:29 |
aline
Messages: 92
Registered: February 2002
|
Member |
|
|
I'm not agreeing with you.
It depends on the structure of your organization.
In our society we don' have the full control of the clients.
Some of them could be forgotten (laptop, remote connection...)
And some people could reinstall oracle client.
I have no control of this.
|
|
|
|
|
|
| Re: auditing the version of the client [message #246533 is a reply to message #246526] |
Thu, 21 June 2007 04:13 |
ThomasG
Messages: 3212
Registered: April 2005
Location: Heilbronn, Germany
|
Senior Member |
|
|
Which could be solved technically.
For example have something in the startup code of your application that checks the local installation.
You could start up sqlPlus and do an
select '&&_SQLPLUS_RELEASE' as "SQLPLUS_RELEASE" from dual;
spooled into some file, and check the version from that.
You could :
1. Start the sqplus that is found int the PATH and spool the version into a file
2. read the file and get the version into a variable
3. put that variable in client_info with dbms_application_info.set_client_info
So it's technical possible, but your client application has to figure out the version first.
You can then even add checks for OS Version, [YourApp] Version, and so on, and put that in client_info, too.
|
|
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
)