My layman's take on errors is that you test, test and test again before anything goes live. Of course, there will always be bugs or unexpected results, but these should be at a minimum for a straightforward registration form.
Ensure that all input is validated and that security is ramped up to the max possible, while still making the form accessible.
The errors encountered need to be tracked. Are they user input errors - e.g. validation errors (example - wrong number of chars in a password field, or incomplete data being submitted). Are they connection or SQL errors (DB). As it seems critical to your company, you need hard data about the nature of the failures to troubleshoot effectively.
I don't know if a %age error will be of much help here. If the proportion of errors are validation-based - could your form design be at fault? Is it too complicated, unintuitive to use? Does it rely on javascript?
Is your manager getting hot under the collar? Losing data may cost money, which may cost jobs. Whether he's a tech person or not, he's probably got a bottom line and will get his bottom toasted by his boss.
Perhaps if you share your code, we could have a look?
diafol
Rhod Gilbert Fan (ardav)
7,792 posts since Oct 2006
Reputation Points: 1,170
Solved Threads: 1,080
Yep, sorry about the business quote :(
On a live site, logging and error tracking are vital. Ensure that all processes can capture errors. So form submission should include server-side validation that will feed into an error trapping routine and log problems - if these are few in number, then user input can be blamed and you may need to look at the form design - are there ways to make it more intuitive or to set default values or enumerated types. Do fields need a small amount of explanatory text to guide users. Sometimes client-side validation can help to reduce the cases of sending invalid data - they may stop submission and highlight errors or incomplete fields.
If the logs show DB connection or SQL errors (you can use the 'die' approach, but a more sophisticated system may be appropriate), check that all input is sanitized properly in order to avoid breaking statements.
If your 'logged-in' status depends on cookies or sessions, again ensure that these are robust.
Error trapping and reporting can be a pain to set up, and in the development phase, it may be a simple 'else' print 'PROBLEM' to screen. I have had good results with the 'try and catch' system. Maybe something to consider.
If you are adept at OOP, perhaps having an error-trapping class may be a way forward. I must admit, I tend to struggle with this.
There are far more experienced members than me on this site who should be able to help you further - but setting up a logging system and error trapping routines would be my approach.
diafol
Rhod Gilbert Fan (ardav)
7,792 posts since Oct 2006
Reputation Points: 1,170
Solved Threads: 1,080
Agree with ardav here, you'll have to log anything that can fail. Personally, I like log4php since you can set logging levels, without having to touch the code. Logging to file is in my opinion better then to database, since the database connection could fail too.
Basically any code that can fail, either with a return result of false (invalid queries), or something that raises an exception (invalid objects) should be logged.
Since you don't have any logging, perhaps you can use your database log, to see if the problems where in queries (unless you didn't turn that on of course).
About the average failure... you are dealing with user input. You have to be completely paranoid, and not trust a user with any decent input. If you fail to check one possible input, you can expect several possible points of failure.
pritaeas
Posting Expert
5,483 posts since Jul 2006
Reputation Points: 653
Solved Threads: 875