« August 2005 | Main | October 2005 »
September 30, 2005
"Rush" Week a Success!
Even though I jinxed myself and reported that our system was working well even before rush week was over, the Bookstore enjoyed a very good rush week this term. The credit goes to Kristi and the Bookstore staff. Also, Bill Nix at Telecom and Paul Lambert at University Computing who got the Werner Center's new switch installed.
For the first half of this week it was all registers, full speed ahead, and not a slowdown or breakdown in sight.
Yesterday, though, the jinx thing did *almost* kick in as our credit card verification service started acting up. The check-out line ballooned like a beached whale in the summer heat as the dreaded "call service center" message was returned for credit card purchases. (This means call them on the telephone - one phone call per customer. Oh man, that slows you down in a hurry!) This is not a function of our system, it was working just fine, but it doesn't matter - service slows way down. Anyway, before I could get off hold waiting for MBS the service started working again - temporary glitch, I guess.
So, except for that one close call, the Bookstore was working full bore, overtime, to serve the students and campus community. Yay!
Posted by rossm at 9:06 AM | Comments (0)
I Guess You Better Wear Your Seat Belt
OK, so I'm one of those guys who does not like the government telling me what to do, ten times over, every time I turn around. I do not like the mandatory seat belt and motorcycle helmet laws, although I do agree it is a good idea to use these items. I just think it should be your choice.
Do you remember when certain groups were trying to pass the mandatory seat belt law (repeatedly, mind you) - one of the big selling points was that the fine would only be $5 or $15 or some minimal amount. Of course, once the law was passed, it was soon turned into another fund raising item for the state and now there are a couple million dollars worth of signs out there reminding us how much it will cost if we don't "click it" (gag).
Well, you can kind of see that I MIGHT be one of those rebels who doesn't always click, but a minor rebel with those missing clicks only for around town trips.
I always figured, hey, how many people get hurt in car wrecks in Monmouth in a year anyway? One or two? I'll take my chances. Well, it might interest you to know that actually there are *about* 25 people injured in vehicle accidents in Monmouth each year. Sure, some of these are minor injuries, but still, it seemed like a lot to me.
Bottom line, I'm back to clicking. Nuts.
Posted by rossm at 8:29 AM | Comments (0)
September 27, 2005
It's "Rush Week" at the Bookstore - New Equipment is Helping
Welcome back students and faculty! The first week of each term has historically been mighty busy at the bookstore, and this year is no different. All seven registers have been placed online and several hundred website pre-term orders have been filled. The new switch that was installed in the WUC earlier this year has resolved our pesky network slowdown issues, and the registers are operating normally, even with the increased traffic load.
Last year we also replaced two modems on the Point of Sale server. One of these modems handles credit card verifications, and it is handling the higher credit card verification volume very well.
Also, we have replaced several of the handheld register scanners over the past year. At the main register, check out our wireless scanner - it is pretty cool and can scan items more than 30 feet from the register (just for fun). We are implementing a long term plan to replace the older Symbol handhelds with newer equipment. So far, we have replaced three of about eleven that need to be upgraded.
Finally, we are nearly done with replacement of the five backup tapes used for daily backups of our system. Our old tape set was three years old, and several of the tapes had started throwing data errors. The bad tapes have been replaced and the entire replacement set should be in use by next week.
All in all the equipment upgrades have really helped reduce the problems we have historically experienced during rush week. Thanks to Kristi, Kris, Margy and the entire bookstore staff for all the improvements which should make things run much more smoothly!
Posted by rossm at 9:30 AM | Comments (0)
AutoCad Upgrade
Thanks to Donna's persistence, the planning department here at the Physical Plant was able to purchase the very latest version of AutoCad - now known as Autodesk Architectural Desktop 2006. (Didn't you like AutoCad better?) Two licenses of AAD 2006 were purchased and installed at the Planning Department, which upgraded our old version (AAD 3.3).
One of the major benefits of this upgrade is that it will allow the planning department to view drawings from any version of AutoCad/AAD. Since they receive drawings from many sources, in many differing versions, this will eliminate the hassle of converting individual drawing files to the 3.3 format.
Posted by rossm at 8:20 AM | Comments (0)
September 20, 2005
Processing Multiple Row Check Boxes - Part III
If you have followed Part I and Part II of this series, then you know that we are using our Oracle database to display a web page. This particular web page we are studying displays all work requests that are open, one per row, with a checkbox displayed at the end of each record. When a user checks one or more checkboxes and presses the "Close Selected Work Requests" button, a javascript function called closeReqs() loops through all the records and creates a marker array with the value "true" set wherever a checkbox was checked. If there are records to be closed, then this statement is executed:
document.hist.submit();
Here in Part III, we will see what this does.
In order to know what document.hist.submit() does, we must go to the form tag in our procedure named "hist". Here is the tag (with < changed to _ for display purposes):
_FORM action = "plant.plant_admin.close_req" method = "post" name=hist>
You can see that the form tag calls the plant_admin.close_req procedure. Let's see what that procedure looks like:
procedure close_req (reqno List, checker List, marker List)
is
vx varchar2(100);
cursor reqs is
select *
from plant.wrk_requests_data
where status is null;
begin
fmm30.template.header;
htp.print('
_script language=javascript>
var arr = new Array();
function goHome(){
window.navigate('''||ADMIN_URL||''');
}
_/script>
_h2>Record of Closed Work Requests_/h2>
_hr 80%>
');
for i in 1..reqno.count() loop
if(marker(i) = 'true') then
update plant.wrk_requests_dataset status = 'C'
where request_no = reqno(i);
htp.print('
_FORM action = "plant.plant_admin.close_req" method = "post" name=document_detail>
_table>
_tr>_td>This request number has been closed:_/td>_td>'||reqno(i)||'_/td>_/tr>
_/table>
_/FORM>
');
end if;
end loop;
htp.print('
_br>_br>
_input type=button class=button value=" Back to Work Request Admin " onclick="goHome()">
');
commit;
end close_req;
You can see that this procedure begins with a cursor reqs that selects all open work requests from the table. A for loop processes the marker array looking for a value of "true". When such a value is found, then the table is updated where the request_no = reqno(i). This is worth stopping and considering. The web browser does a really neat thing for you when multiple records are displayed on a form. It automatically creates arrays for each of the text box, check box, and hidden objects. All the data for one record can be found at the same index. So, marker[i] and reqno[i] can be matched up to get the request number that needs to be closed. This is very powerful stuff!
From here it's all downhill. The work requests that are closed are displayed as feedback information for the user, and finally there is a button that takes the user back to the main page. The main page will once again display the open work requests, but not the ones that we just closed.
Let's review. Our goal was to create a way for the user to see all open work requests, and then to easily close one or more of them. We displayed a list of open work requests, one to a line, with a checkbox at the end of each line. The user then selected the work requests to close by simply checking the appropriate box or boxes and clicking a button. We then processed the request, making sure that at least one box had been checked, and creating a marker array which held a value of true at the index of the record to be closed. We then looped through the marker index and closed each record at the same index of the "true" marker value.
I hope you can see a way to use this technique to make your application more efficient and more user friendly.
Posted by rossm at 1:45 PM | Comments (0)
What's On the Shelf Right Now?
I have attended the following formal training (none of it within the last 14 months):
Intro to Oracle: SQL and PL/SQL August, 1999
Develop PL/SQL Program Units April, 2000
Enterprise DBA Part 1A November, 2001
MBS Systems Operation Workshop 2002 or 2003
Posted by rossm at 11:50 AM | Comments (0)
September 8, 2005
Processing Multiple Row Check Boxes - Part II
In Part I we looked at a way to display all open work requests together with an empty check box for each one. Now, we need to decide how to figure out which of these records is ready to be closed (Remember, a work request is closed if the status column in the main table = 'C'). How on earth to do this?
The first step is to be notified by the user that it's time to close the records which have been checked. I used a button like this:
_input type=button id=closer class=button value=" Close Selected Work Requests "
onclick="closeReqs()">
It looks like this:
So, there we are, ready to close the checked work requests. You can see from the code above that the button press calls closeReqs(). This is a javascript function, and here it is:
function closeReqs(){
if( confirm(''Close the selected Work Requests?'') ){
/* Calls new_preq */
document.hist.action = ''plant.plant_admin.close_req'';
var good = false;
var x = document.hist.checker.length;
if(x== undefined){
good = true;
document.hist.marker.value = ''true'';
}
else {
for( i = 0; i < document.hist.checker.length; i++){
if( document.hist.checker[i].checked == true){
good = true;
document.hist.marker[i].value = ''true'';
}
}
}
if(good){
document.hist.submit();
}
/*This alert makes sure at least one line was selected.*/
else {
alert(''You must check at least one box.'');
document.hist.action="plant.plant_admin.close_req";
location.reload;
}
}
}
Yes, it's fairly long. Have you seen the if(confirm(...)) javascript before? It is pretty neat - it will display a dialogue box asking the user whether they want to "close the selected work requests?" If they answer yes (0r OK), then we proceed to close the work requests. If they answer no (Or CANCEL), then the function essentially does nothing. Also, you will see that the last chunk of code below the alert is just checking to make sure at least one checkbox was checked. If not, then an error message is displayed.
So, let's focus on the meat of this javascript function. First, the variable x is set to the length of the checker array (in other words, the number of records that are displayed as open). If x is undefined, then good is set to true and marker is set to true. This is the case of only one open work request being displayed, so no array was created. The "else" portion of that if statement is where the action is at, and covers the normal case of more than one record displayed, and one or more of the checkboxes checked.
In the normal case, then, we loop through the records one at a time and check whether the checkbox is checked. If the box is checked, good is set to true and marker[i] is set to true. The net result is that good is true and the marker array has values of true wherever there was a matching checkbox checked. This is what we will use next time for actually closing the proper records.
One last comment about the good variable (boolean). Good is used to determine whether or not we have one or more records to close. If good is false, then no checkboxes were actually checked. If good is true, then we have some records to close.
In summary, Part I of this series showed you how to display multiple records on a web page, with each record having a checkbox and a hidden marker value. Here in Part II we have seen how to create the "Close Selected Work Requests" button, and how the closeReqs() javascript function has modified the marker array with a value of true at the index corresponding to the record index we wish to close. In Part III we will figure out what happens when document.hist.submit(); is called, and it is here that we will actually do the work of closing the appropriate work requests. See you next time!
Posted by rossm at 9:45 AM | Comments (0)