Oracle on Unix vs Windows

[tommy]

Are there any special considerations if using Oracle on Unix vs windows ?

I have problem with a system that works fine on a windows oracle server but on a unix oracle server there are weird errors.

I can't find the compatibility matrix for 6.2.4 on HP's site so I couldn't check that.

I assume that HP supports both Oracle on Unix and Windows but does anybody for this for a fact?

[glg]

Yes, they support oracle on unix. There might be some specific gotchas though. What version of Oracle and what Unix?

[benvargas]

Weird errors... example? I have installed SM7.01 on a CentOS VMWare (basically opensourced non-branded redhat linux) with Oracle XE, I didn't have any problems.

[tommy]

Server: Oracle Enterprise Edition Release 9.2.0.5.0 - 64bit on HP-UX B.11.23
Oracle client Release 9.2.0.1.0




The error is that on all searches in interaction and incident SC prefiixes all searches with owner.name#"sdapprover" on the dev system and on the test system it prefixes them with owner.name#"knu.ext" (it does not happen in change, problem or request). If I convert the system back to P4 the error condition still exist so it is a permanent change that happens when converting to oracle on the customer database.

But if I take a backup of the P4 files pre-convert and copy them to my laptop and do a conversion on a 100% default installed oracle 9.2 everything works fine. No errors and no prefixes in searches.

The major difference is that the customr has oracle on unix I have oracle on windows and the customer obviously has setup their oracle to their likings and I have a 100% default oracle installation. I even used the demo database instead of creating a new empty.

[glg]

Wow, that's really weird.

I know on Solaris, there's a restriction that you have to use the 32-bit Oracle client. You can connect to a 64-bit server, but SC's shared libraries only handle 32-bit. Pretty sure that if that was the problem you'd be getting a much more serious problem then that though (ie no connection at all).

[mateuszk]

The error is that on all searches in interaction and incident SC prefiixes all searches with owner.name#"sdapprover" on the dev system and on the test system it prefixes them with owner.name#"knu.ext" (it does not happen in change, problem or request). If I convert the system back to P4 the error condition still exist so it is a permanent change that happens when converting to oracle on the customer database.

Additional info, please:

1. were You the person that initially converted the files?
2. how can you be sure the pre-RDBMS (clients' P4 prior to the conversion) system is in exactly the same state as the production (make sure no changes to the prod. system were applied after the conversion)
3. did you try this with an OOB P4 on client's env?

Personally, I find your situation quite strange.
I've seen a lot of conversion errors on different envs (as, certainly, have You )
but they were usually breaking some functionalities, not making "an improvements" by adding clearly readable options to some of the queries . This definitively looks human inflicted to me.
I'd rather take a look on the search process itself (DO, DS, Process, State etc.) other than looking for a cause in the conversion to RDBMS.

[tommy]

To answer your questions:

1: yes
2: there is no production system yet but the p4 files works
3: yes

We have checked everything we can think of including all you mention. The problem IS the conversion there is absolutely no doubt about it. Remember I did a conversion with the same P4 files on my own laptop without getting that problem. So it must be something in the customers environment.

[mateuszk]

Wow! This is weird.

Another idea, did you check 6.2.5 on this env?
Did you report this to HP Support?

I might try it, just for the sake of experiment, on OOB SC & HP-UX system on my side, but I doubt this would produce the same results.