Continuing on in the cool stuff we’ve been working on series, I wanted to post something about a topic that goes way, way back.
Many years ago, Dave Yoder of Rainbird asked me at a DMUG user conference about how to get variable expansion support for file name references when building a project inside Application Designer.
Without having variables that you can expand, you always have to remember to change the name of the file that will be generated each time you build records/views/indexes, etc. It’s really easy to forget and lose old copies. If you care about saving copies for yourself or for audit purposes, then it gets tiresome to always remember.
Here’s some screenshots of what we have put together to address this particular issue. The first two screenshots show the Application Designer Build Settings dialog with the build log file set to c:temp%YEAR%%MONTH%%DAY%PSBUILD_%DBNAME%.log. Here we are just changing the log file, but it works for any of the files that would get generated when doing builds in Application Designer.
The strings that are between percent signs (YEAR, MONTH, etc.) are variables that get expanded out to real values at the appropriate moment.
Here is what it looks like when you actually run the build.
As you can see, the generated log file has been created as c:temp2009126PSBUILD_PTSYS.log. Since today is January 26, 2009 and I was working in a PTSYS database, that’s exactly what we expected
There are also tokens for things like current hour, minute, second so if you like to do lots of builds in a short time frame you might want to take advantage of those as well.
In addition to things like date/time and connectivity info, there are also tokens that are supported by other Grey Sparling products.
For example, when you are using Grey Sparling Version Control for PeopleSoft you can also do things like reference which ticket number that you are currently working on. Here’s the build settings showing the log file setting as c:tempTicket-%TICKET%PSBUILD_%DBNAME%.log
After running the build (note that our version control plugin is active now; it has to be to supply the current ticket number), you’ll see that the build log file was generated as c:tempTicket-4PSBUILD_PTSYS.log. We could have included the date/time tokens as well if we had wanted to.
Now the build scripts, log files, etc. can easily be associated with the work that you are doing, and even automatically attached to the ticketing system if you want. That helps when your developers and DBAs need an audit trail of these sorts of activities. Fun to use and keeps the suits happy!
So if you run into Dave Yoder at a conference, be sure to thank him for coming up with the idea (and asking about it enough that it finally got built!)
Labels: 2009, ApplicationDesigner, Database, Products, VersionControl
David Kurtz has a good tip on his weblog about how to get rid of an annoying little bug in the index management in Application Designer. David knows what annoys DBAs about PeopleSoft – he wrote the book on it(literally).
The underlying source of the problem has to do with the fact that some of the internal PeopleTools code still thinks that it is supporting some platforms that are actually not supported (Allbase!).
The problem of code cruft in PeopleTools is actually something that I’ve had in my list of blog topics to write about for awhile, but it’ll have to stay in the queue a bit longer. For now, check out David’s post for how to make Application Designer behave 🙂
A common headache for DBAs managing PeopleSoft applications is not knowing which user a particular piece of SQL is being executed for. This happen because the SQL is being executed by the application server under a privileged user account and not the PeopleSoft user (who probably doesn’t even have a database login).
The DBA can go ahead and kill the connection at the database, but they can’t explain to the user what happened. Of course, the end user just sees it as a PeopleSoft error (PeopleSoft does not handle killed connections very gracefully) and they try it again. Which just annoys the DBA even further. A vicious circle indeed.
At the Mid-Atlantic RUG last week, this topic came up in a few different discussions. Some of the DBAs there weren’t familiar with the EnableDBMonitoring option for PeopleSoft application server domains.
When this is turned on (and it’s on by default in PeopleTools 8.43 and up), then each time the application server begins doing work on behalf of a different user than it was previously doing work for, it will set a variable in the database session with information on that user.
- Oracle. You can see the information in the CLIENT_INFO field of the V$SESSION Oracle system view.
- SQL Server. The information is available in the context_info field of the sysprocesses system view in the master database. This is a varbinary field, so you’ll need to cast it as varchar to view the data. There is also a PeopleSoft version of the sp_who stored procedure (called sp_pswho) that will return this information. Unfortunately this stored procedure does not get installed automatically when you install PeopleSoft. You’ll need to do it manually. A script to install this can be found in appendix B of the SQL Server for PeopleSoft Performance Tuning Red Paper.
- DB2/zOS. The DISPLAY THREAD command will display the PeopleSoft user ID in addition to it’s regular information. Other DB2 platforms (Windows, Unix, Linux) do not support this command.
- Sybase. Later versions of Sybase support this feature, but I’m not sure about how to access the information in the database. I would assume that an additional column was added to the sysprocesses view (similar to SQL Server), but I don’t have access to a Sybase installation to verify that at the moment.
- Informix. Informix does not support this feature.
Labels: Database, Performance