Managing Various Oracle Client Versions
We have about 10,000 desktops/laptops, and about 2000 applications installed on them (yep, 2000). We deploy via MSI/MST/SMS 2003 and have SMS collections associated with AD groups. We have a split of 4 businesses, each managing their own applications and Oracle databases (apart from the deployment function - that's done centrally).
This has all lead to a situation where we have a range of Oracle client versions installed - from 6i 10 10g. We have applications which use various methods of connection - ODBC, OLE, OLE .Net, and various versions of each of these drivers. We have DSNs coming out of our ears. In summary - it's a big mess.
We don't have much control over the applications, so can't force them to move to a common database version/connection mechanism. This leaves us in a situation where it's really hard to deploy any Oracle application, or modify any Oracle database version without breaking at least one application on a large number of machines. We think we can get some Oracle client versions to co-exist on a machine, but not all of them. Our plan is to put together a set of say 5 'Combi-Packages'. Each of these will hold any Oracle components we can get to co-exist, and will have an associated set of applications which it's been tested against.
My question is - does anyone else have the same problem (this would make me feel better), and has anyone else solved it (this would make me ecstatic)!
Thanks, Jason
This has all lead to a situation where we have a range of Oracle client versions installed - from 6i 10 10g. We have applications which use various methods of connection - ODBC, OLE, OLE .Net, and various versions of each of these drivers. We have DSNs coming out of our ears. In summary - it's a big mess.
We don't have much control over the applications, so can't force them to move to a common database version/connection mechanism. This leaves us in a situation where it's really hard to deploy any Oracle application, or modify any Oracle database version without breaking at least one application on a large number of machines. We think we can get some Oracle client versions to co-exist on a machine, but not all of them. Our plan is to put together a set of say 5 'Combi-Packages'. Each of these will hold any Oracle components we can get to co-exist, and will have an associated set of applications which it's been tested against.
My question is - does anyone else have the same problem (this would make me feel better), and has anyone else solved it (this would make me ecstatic)!
Thanks, Jason
0 Comments
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
kkaminsk
19 years ago
This is the worst Oracle environment I have ever heard of. I can suggest is to standardize the Oracle environment in your company or do what Suncor did and buy Softricity's Softgrid platform. With Softgrid you could take your legacy Oracle environments and put them into nice little virtual environments that don't modify the desktop. You also could go with housing the applications on Citrix which is the more traditional route to get horrid applications off of the desktop. Still not every app likes Citrix (multiuser issues) or Softricity (services / drivers).
You would trade in your integration issues for some peace of mind but then you would be spending money on a new technology. It would be a hard sell to management unless managing your current Oracle environment is consuming significant man hours to support and integration issues are causing lengthy delays in provisioning applications. At the very least there are some ways of dealing with non standard environments but they are not necessarily cheap.
You would trade in your integration issues for some peace of mind but then you would be spending money on a new technology. It would be a hard sell to management unless managing your current Oracle environment is consuming significant man hours to support and integration issues are causing lengthy delays in provisioning applications. At the very least there are some ways of dealing with non standard environments but they are not necessarily cheap.
Posted by:
Qazmo
18 years ago
Jason,
Assuming you don't live in a fantasy world where you can re-engineer all of your organisation's Oracle apps with no impact, I have to say "Welcome to the real world of Oracle applications!"
I administer apps that use several versions of Oracle components - from Developer 6i up to 9i and a creaky old version of 16-bit ADE in between and (thus far) have - through judicious use of forcing the settings I know each app needs to work down to the client at runtime - managed to have all the apps continue to work and all the versions to co-exist.
I'm realistic enough to know that - sooner or later - something's going to break something else, but so far everything's fine.
Assuming you don't live in a fantasy world where you can re-engineer all of your organisation's Oracle apps with no impact, I have to say "Welcome to the real world of Oracle applications!"
I administer apps that use several versions of Oracle components - from Developer 6i up to 9i and a creaky old version of 16-bit ADE in between and (thus far) have - through judicious use of forcing the settings I know each app needs to work down to the client at runtime - managed to have all the apps continue to work and all the versions to co-exist.
I'm realistic enough to know that - sooner or later - something's going to break something else, but so far everything's fine.
Posted by:
andler
18 years ago
Hi Jason
I have read your story, an as the others say, this is not uniqe for your organization.
I have been with many and seen it all over.
What I usually suggest is to make the programs dependent of the correct version of oracle client. The Oracle client is installed together with the program if not installed before.
Each program depending on oracle will launch using av script. The script put all necessary information about oracle into registry and in tnsnames.ora (if needed) before it launches the application.
br,
andler
I have read your story, an as the others say, this is not uniqe for your organization.
I have been with many and seen it all over.
What I usually suggest is to make the programs dependent of the correct version of oracle client. The Oracle client is installed together with the program if not installed before.
Each program depending on oracle will launch using av script. The script put all necessary information about oracle into registry and in tnsnames.ora (if needed) before it launches the application.
br,
andler
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
