This content has been marked as final. Show 25 replies
You just made my day, that solves the problem.
I should take you to lunch .... will you be available? lol!
I really appreciate that.
Ok, next time I'm coming to South Africa <smiley>
The problem could come from the fact you gave the database name in lower case when deploying the db image, have you not ?
At this stage :
I think I did.
All I remember was that I gave the dbname somewhere in lower case but the exact place I can't spot.
You're "The Man".
Good work Nicholas on figuring this one out.
As pointed there is a newer version of the HCM 9.1 template which is based upon PeopleTools 8.51.02. Good reasons to use this are:
- A lot of problems that were reported with the earlier version of the template have been resolved
- The newer one makes the Application Designer binaries available - these can be ftp'ed from the template and used on a Windows client
- Integration Broker Gateway and Report Nodes are setup in the VM when booted
- COBOL runtime and compiled binaries are included if you accept the Terms and Conditions during VM initialization
- PIA and Application Server run in the same VM saving diskspace and setup time
In general we encourage people to pull down the latest demo templates as we intend to make them available soon after the GA of Feature and Maintenance packs for each of our applications.
A lot of the issues reported by Nicholas have been resolved in that template. He has terrificly helpful in that regard.
Thanks Mark for kind words.
Frankly speaking, I even did not try a database name in lower case for the OVM db, probably needs a try.
This issue remind me a very similar case with in the Peoplesoft Database Wizard for Oracle DB, for some mysterious reason, it does not support database name in lower case. Is it because of that PSDBOWNER.DBNAME ?
Based upon your description I would tend to think that this is a general issue that is not specific to these templates. I will try and find out from the DCW people to see if this is one of those, "oh yeah, obviously you use upper case" things that was never actually documented. Maybe DBAs just always err on the side up uppercase consistency across the board, I just amn't sure because I don't work in that area. Anyhow, I will try and do a little sniffing on this one.
I will try and find out from the DCW people...Sorry to ask, but what is DCW ?
Maybe DBAs just always err on the side up uppercase consistency across the boardSince the given example name of database is in upper case (TESTDB), I assume so too. But in most of the shops I was working for, they tend to give a lower case db name in *nix env (which is generally not an issue with manual db creation).
Thanks for your attention.
Database Configuration Wizard. Sorry.
That's interesting about the lower case on UNIX/Linux. All the more reason for me to follow up on it here.
I can confirm the issue of Kareem. After testing a PSOVM database server deployment giving a database name in lower case, the column DBNAME in PS.PSDBOWNER is also coming in lower case.
Would it be possible the make a proper update of that column in the deployment script ? Anyway, there's already an update since the given dbname is different than the default one, just add UPPER() function around the given DBNAME. Or at least make a test to prevent DBA to make that, err, that kind of mistake ?
Here two screenshots to get clear picture if needed :
I think that is a very reasonable request indeed. Personally my preference is to trap this at the time of entry because it can alert the user and doesn't change any of our core functionality in terms of how we lay down demo DBs even in a bare metal deployment. It also appears on initial investigation that this is a best practice as opposed to something that is documented out loud in PeopleBooks / Upgd or Install Guides. We're still chasing it down though so feel free to contradict this assertion.
We'll definitely do something in the next template update though ... assuming it is the piece of cake I assume.
I thought that was peanuts to change the update script.
I did a quick round in the template scripts (however I'm not a OVM specialist to determine what is the underlying impact), and saw the following sed command which could be highly interesting for our case :
We could change that sed command line to replace DB_NAME by upper($1) - or in the following script
[root@psovmhcmdb ptdb]# pwd /opt/oracle/psft/ptdb [root@psovmhcmdb ptdb]# more scripts/updatedb.sh UPDATE_DB_FILE=/home/oracle/scripts/updatedb.sql sed "s/DB_NAME/$1/g" $HOME/templates/updatedb.sql > $UPDATE_DB_FILE sqlplus -S -L / as sysdba @/home/oracle/scripts/updatedb exit 0 [root@psovmhcmdb ptdb]#
If we replace the update by the following line, we should not have any troubles :
[oracle@psovmhcmdb templates]$ pwd /home/oracle/templates [oracle@psovmhcmdb templates]$ more updatedb.sql connect SYSADM/SYSADM update ps.psdbowner set DBNAME = 'DB_NAME'; update psoprdefn set ACCTLOCK=0; commit; exit [oracle@psovmhcmdb templates]$
... update ps.psdbowner set DBNAME = upper('DB_NAME'); ...