After installing a series of updates (852825, 872267, 872523, 874418), I ran into a SQL error. I am not sure which update it was, and actually, the find definition references pointed to 808749, which is HRMS 9.1 Bundle #1.
As I am not able to open a ticket on this issue currently, this is what I did to fix the problem …
I noticed this error in one of my CI logs.
SQLExec: 3 select list items in parameter list, but SQL has 1 select columns. (2,124) HP_RTBC.RTBCMain.OnExecute Name:Job_RTBC PCPC:4183 Statement:89
Called from:HP_RTBC.RTBCMain.OnExecute Name:MainProcess Statement:9
Called from:JOB.LASTUPDOPRID.SaveEdit Statement:3(2,124)
As a result, I couldn’t hire anyone. The problem appeared to be this line:
I decided to inspect the SQL, and I found this code:
FROM PS_DEPT_TBL A
AND A.DEPTID =:2
AND A.EFFDT = (
FROM PS_DEPT_TBL B
AND B.DEPTID = A.DEPTID
That’s the problem. The SQL only has 1 field in the select list (USE_ENCUMBRANCES), and the PeopleCode expects 3 for the 3 variables (&DeptUseEncumbrances, &ProcOption, &HP_AUTO_RTBC);
I did a little research, and as best I could tell, this PeopleCode is the only one that uses the SQL definition.
I couldn’t do a Find Definition References on the Application Package PeopleCode, but I could do a SQL query to determine which projects it was involved in:
SELECT * FROM PSPROJECTITEM
WHERE OBJECTVALUE1 = ‘HP_RTBC’
AND OBJECTVALUE2 = ‘RTBCMain’;
These are some of the updates that I just installed, so I bet that was my problem.
So, I updated the HP_RTBC_INSTALL_DEPT_SEL SQL definition and added the two extra fields as best as I could figure.
FROM PS_DEPT_TBL A
AND A.DEPTID =:2
AND A.EFFDT = (
FROM PS_DEPT_TBL B
AND B.DEPTID = A.DEPTID
I had an issue with some indexes that would not create. The database complained that the table had duplicates in it that violated the index. For me, the table was PS_AUC_HDR, but these steps should work for any table. Maybe some of the techniques will be helpful too. Also, if you know a better way to take care of the problem, please comment.
This post is a follow up to this thread that I opened. Unfortunately, at this point, I haven’t figured out what I am doing wrong. If you see something, please comment either here or on the thread at Oracle Forums.
I am trying to install the Global Payroll Rules for 856737 and 857845 (both Non-Rule + Rule).
I found that I do this at this navigation: Set Up HRMS > Product Related > Global Payroll & Absence Mgmt > Elements > Manage Global Payroll Packages > Apply Rule Package:
I thought I had my environment built, but I keep finding little problems. Well, this time it was the report repository. I got the reports posting, and I thought I was home free. The solution ended out being simpler than I thought.
Let me just walk you through some of the things I checked to see if it helps any of the problems you may be having.
My specific error was: “Site name is not valid“.
The cause was that my Report Repository path was not configured. PeopleTools > Web Profile > Web Profile Configuration
The catch was that somehow I got mixed up on which Profile I was using. You can check your profile easily from the Web Profile History:
On the search page of the Web Profile History, you can see which profile was loaded last. You can sort the list by clicking on the “Profile was Loaded” heading. If you click a second time, it will sort it descending. Notice that previously I was using the Dev profile on port 8000. When I last installed PIA, I must have configured it for the Prod profile on Port 80. So now, I need to configure things on the Prod profile.
Here’s some other things you can check. Make sure your distribution node is connected to your server:
Then, check the Report Node. Make sure the URL matches the URL you are using to connect to the Portal. The domain name and port should match. If there is no port number like mine, you are using port number 80. Then, check the portal domain name. For me, I am using the default “ps”.
According to this post, you also need to check the local node. In PeopleTools > Portal > Node Definitions, look for the node with Local Node set to “Y”:
Now, make sure the node is set to password authentication. I am not sure what else to check here.
Finally, check your configuration.properties file for the path. I am not sure what this setting controls because mine was wrong just now, yet it seemed to be working.
Look in <PS Home>\webserv\<domain>\applications\PORTAL.war\WEB-INF\psftdocs\<domain>\configuration.properties.
I had an issue recently where I needed to trace a process to try to determine where a bug was occurring. So, I decided to try to document how I could setup tracing on a single process.
To enable tracing, you need to open the process definition. Online, navigate to PeopleTools > Process Scheduler > Processes. Then, search for the process that you want to trace. Make sure that you change the search page so that you are searching by process name and not the process type. Once you have the Process Definition open, go to the Override Options tab. Then, change the parameter list to “Append” and enter the desired trace settings.
My options aren’t to say that Ketan’s are wrong. I just cut out some of the options I wouldn’t use to trim the extra info in the log file. I also normally use traces for troubleshooting, so my options are tuned for that.
You can read below for details on what each of these does.
The -TRACE option sets the tracing for the App Engine program generally speaking. For example, it can turn on the trace output that displays which steps run in which order. Here are the different options (from the psappsrv.cfg file):
1 = Trace STEP execution sequence to AET file
2 = Trace Application SQL statements to AET file
4 = Trace Dedicated Temp Table Allocation to AET file
8 = not yet allocated
16 = not yet allocated
32 = not yet allocated
64 = not yet allocated
128 = Timings Report to AET file
256 = Method/BuiltIn detail instead of summary in AET Timings Report
512 = not yet allocated
1024 = Timings Report to tables
2048 = DB optimizer trace to file
4096 = DB optimizer trace to tables
If you’ll notice, 135 is “Timings Report to AET file”, “Trace Dedicated Temp Table Allocation to AET file”, “Trace Application SQL statements to AET file”, and “Trace STEP execution sequence to AET file”. My preference just leaves off the Timings Report. I think the timings report would be good for performance tuning, but if you are troubleshooting, it is just overhead.
The -TOOLSTRACESQL option specifics the SQL tracing besides the SQL executed by steps in an App Engine program. This would include any PeopleTools system database communication, and more importantly, it would include any database access caused by a component interface driving an online screen.
Here are the options:
1 = SQL statements
2 = SQL statement variables
4 = SQL connect, disconnect, commit and rollback
8 = Row Fetch (indicates that it occurred, not data)
16 = All other API calls except ssb
32 = Set Select Buffers (identifies the attributes of columns to be selected
64 = Database API specific calls
128 = COBOL statement timings
256 = Sybase Bind information
512 = Sybase Fetch information
1024 = SQL Informational Trace
Again, the recommended setting is 31, which includes: “All other API calls except ssb”, “Row Fetch (indicates that it occurred, not data)”, “SQL connect, disconnect, commit and rollback”, “SQL connect, disconnect, commit and rollback”, “SQL statement variables”, and “SQL statements”. My choice would just be to see the SQL statements and the variables because that is the most important information. Commits and Rollbacks can be important, but you generally know when those happen and don’t need the extra information. The fetches will tell you how many rows you will receive but it won’t give you any of the data, so it just clutters the trace file. Those options can be helpful, but unless you need them, I would leave them off.
Finally, the -TOOLSTRACEPC option turns on tracing for PeopleCode. This could be PeopleCode steps in an App Engine, or it could be PeopleCode in a component accessed by a Component Interface. Here are the options:
2048 = Trace each statement in program (recommended)
The recommended option is 1984, which includes: “Show function return value”, “Show parameter values”, “Trace internal function calls”, “Trace external function calls”, and “Trace start of programs”. For me, I want to see what PeopleCode is running, so the most important option would be 2048 — Tracing each statement. The variable assignments, fetched values, parameter values, and function returns all show the data as it flows through the PeopleCode, so I find those helpful in troubleshooting. For me, that adds up to: 3596.
Recently, I have been doing a lot of Memory troubleshooting.
Here are some windbg commands that helped:
Load the sos module (for .Net 4.0)
.loadby sos clr
List all of my object specific to my program:
!dumpheap -stat -type <parent namespace>
List all the instances of a particular object:
!dumpheap -type <namespace>.<object class name>
List references to the object:
Break on garbage collection:
!findroots gen any
List references to the obect (must break in garbage collection):
Show sizes in the memory:
List large strings in memory:
!dumpheap -type System.String -min 10000
Then, I also found that you can use the SOS module with within Visual Studio. First, in the project settings, I had to go to the Debug tab and check “Enable unmanaged code debugging” under “Enable Debuggers”. Then, in the immediate window, I could run the following command:
I thought my problem seemed to be related to the Data Grid view just like this forum post. The post lists a code fix, but my problem is finding out where I place the code. This blog mentions putting the code in the Form Close, but my problem is during the execution of the program.
Actually, it ended up being that I was loading a hidden column into the grid that was taking a lot of memory. I had a Select * SQL statement, and I had to list only the fields that I wanted in memory.