On average, about twice a year, an error is reported within the Online Employment Application. Last week, one of these errors occurred. The symptoms would seem to indicate that two applicants could have hit the "Submit" button at approximately the same instant in time (we're dealing with nanoseconds here, of course). As a result, one applicant saw "bad" data in the final confirmation page, containing information from another applicant. So, I investigated how the application is using the APPTID field, and I think I can change the code to greatly reduce the chances of this kind of error occurring again. I hope to have the changes in place within the next week.
Recently in Online Employment Application Category
A technical problem with the Online Employment Application was reported to me last Friday. I was the last Programmer to work with this code, so I was the logical person to contact.
This latest glitch surfaced when attempting to complete our form after navigating to our site through the Statesman Journal newspaper's link to the CareerBuilder site. The particular link to our site opened in a frame with a very long, complex URL. Problems were reported at various stages when completing our form, including not being able to link to the various pages of our form and seeing other applicants' data after clicking the final Submit/Print button.
In testing our form by just going through our website, I concluded that the PL/SQL application itself was working fine and that the Oracle tables were all in tact. At this point, I wasn't sure if the problems were the result of the recent web migration on campus, or due to something that might have changed within the CareerBuilder site. As Human Resources staff were justifiably concerned about the impact of the technical problems, I was asked to temporarily disable the form.
By this time, I thought it might be best to try launching our form in a separate browser window; right-clicking the link to the form, then chosing to open in a new window displayed everything with our standard URL, and the form worked properly. I decided to wait until Monday in order to talk to Ron before making changes to my HTML. Ron suggested calling our form using the target = _top option within the A HREF tag. After working through a few tests together, Ron knew which pages on the Human Resources website to edit with this change. This particular solution should prevent similar problems in the future, not only with CareerBuilder, but with any other external sites that link to Human Resources.
Once he had all of the links updated, I tested the form using both Internet Explorer and Firefox. The form displayed with our "correct" URL, and everything seemed to work properly as I progressed through the application. Human Resources staff were glad to have the form in operation once again.
Last week I migrated an updated version of this application into production. I expect this new production version to resolve two main issues:
â—? If applicants used their browser's back button to answer the question regarding completion of a High School education or a GED Certificate more than once, this resulted in run-time errors when HR staff attempted to read the application.
â—? If applicants entered text that was too long for text boxes within the applicatin form, a run-time error resulted.
Among my recent projects and tasks, I've taken some time to work on improvements for the Online Employment Application. I believe I have resolved several small problems with the program, and now have the changes in place in a test environment for HR staff to examine.
The initial technical issue had to do with applicants submitting multiple entries for the completion of a High School education or GED certificate. This results in a run-time error when HR staff attempt to retrieve a completed application. I reorganized the series of forms to place this question in a slightly different area of the application.
We then discovered problems (again, resulting in run-time errors) when applicants enter text that is greater in length than that of the text areas. I believe I have solved this by incorporating local variables that are the same lengths as the table columns, then inserting these values into the Oracle tables. This results in longer answers being truncated to fit the variables and tables.
My goal is to put these changes into production by the end of April. Later, I'll modify the application to give HR staff the capability to send applicants an email confirmation that their completed form has been received.
In my test schema, I have developed the capbaility for Human Resources staff, as part of the review process, to quickly send an email message to applicants indicating that their completed form has been received. The email message includes a link to the applicant's completed online form. I still need to develop some error-checking with the applicant email address field to validate the format of the address. A possibility here would be to change the form to have the "@" character hard-coded within the address field.
Human Resources staff would like to have the capability to send job applicants an email message to acknowledge receipt of their completed employment applications. I now have the capability, through a test package, to send a simple email message within Oracle. I modified a procedure that Mike Ross and I have been using with the Wilbur to Aero migrations. The original code placed too much information in the subject line; I corrected this by printing the characters chr (13) and chr (10) as end-of-line characters.
I have placed a test copy of my changes to the Online Employment Application in the HR schema for testing by Human Resources staff. Once they have had a chance to test things and we've worked through any needed changes, I'll put this version into production.
Changes to the application include creating a new table to contain applicant's response to the question about completion of a High School diploma or GED certificate and reorganizing the system to separate this question from the remainder of the Education section, as well as some wording changes on various pages.
Once HR staff have a chance to test the application, I expect to quickly make any needed changes and have the revisions into production by the first part of next week.
In an earlier blog entry, I discussed how I might use a cookie to detect whether or not applicants had answered the question pertaining to completion of a High School diploma or GED certificate. Because of difficulties I had in implementing the cookie, I decided to pursue another solution, which I believe will be better for the long-term.
In working with Human Resources staff, we agreed to separate the question for High School/GED completion from the remainder of the Education section of the application. We also agreed to create a new table for that particular question. This results in that question residing in its own section of the application, similar to the section for personal data.
Making the changes to the PL/SQL code and adding the new table proved to be fairly simple, and I have these changes working in a test environment. I will change some wording on the administrative pages of the program and will make the test application available for HR staff to test. I expect to have this in place by Friday, January 6.
Whew! What a headline! I wonder how many comments from off-campus I'll get for this blog.
Seriously, though, these are the concepts and issues I'm dealing with in trying to resolve a problem with the online employment application. The Oracle application works well with the exception of the question dealing with applicants' completion of a high school diploma or GED certificate.
After answering that question, if applicants click the browser Back button to answer the question again, two entries are inserted into an Oracle table. This results in an error page when HR staff try to view the completed applications.
With my current knowledge of PL/SQL and web development, I believe the best solution for this error is to use a cookie. Each time applicants answer that particular question, the next step will be to check the value of the cookie. If the cookie has not yet been set (the first attempt to answer the question), the data will be inserted into the table and the cookie will be set. When applicants attempt to answer the question again, the code will determine that the cookie is already set, the data will not be inserted into the table, the applicant will get an appropriate message page, and will be allowed to complete the remainder of the employment application.
