I need help with sub validate_record.

Appearently the sub reads 0 as being a null or blank entry, as a result, even if 0 would be a valid entry in a required field.

I require some fields to be filled in even it the value is 0. Basically, "---" or just blank are invalid only.

My form is quite large and items may be missed if the user isn't paying attention so I can't simple turn off the required field option.

Need to modify sub validate_record to allow 0 to be a valid entry.

Thanks,
beetleman

Marcus L. Griswold

I would want to also know if the field is alpha or numer, I am assuming alpha.

I see that in the config file you can specify valid values as reg expressions, so if you can determine the regular expression for

not --- nor "", then add it to the config file?

he is my best guess at that reg expression and maybe Paul will correct me.

!("---"|"")

Sorry I know that's way so wrong.

Okay, here's the deal.

When I add a new record, any field with "0" (zero) in it is replaced with a blank. In the case of select menus, "---" is selected instead of "0".

It is important that fields with a zero value in them be saved correctly. Otherwise, users will not be able to search for "0". Blank and --- are used as any during searches. I considered using N/A or None but this would further complicate the search process, javascripts, and the general look and feel of the database.

As an example, toys that children ride:
Toy Wheels
pogo-stick........0
unicycle............1
bicycle..............2
tricycle.............3

In this example, 0 is a valid and important value for wheels as related to pogo-stick

So, how do I modify sub validate_record or sub parse_form to prevent 0 from changing to nothing? (Odd question I know, 0 is the mathmatical representation for nothing)

I could really use some help here. Been stuck on this for a week (eternity when setting up a web site).

Thanks,
beetleman

Marcus L. Griswold

For the "wheels" example, certainly it will work if data type is set to numer in the config file? I know that does not help if it is a select list with the default as ---

If you must have a select list for a numer field, then maybe the default could be -1 (or blank) and the valid entries could be set to numbers greater or equal to zero.

Maybe something like this in links.def

type => [0, 'numer', 1, 1, 1, '', ''],


and this in the html



untested.


Gene
"The older I get, the more I admire competence, just simple competence in any field from adultery to zoology."

I guess that I should explain better. In every field that has a value of 0 entered into it, reguardless of required field or not, upon submit, all zeros are replaced with either a blank or "---" even if 0 is the default value. If 00 is added into a text field, 00 is added to the db.

This result occurs for both 'alpha' and 'numer', required field and non-required field, text fields and select fields, basically where "0" is the only value in the field, it is replaced before being added to the database.

This is the cause for the error message mentioned in the original posting.

For reasons unknown to me, db.cgi parses 0 to the null value. Null value in this case is simlpy blank. When build_select_field comes to a blank, is automatically selects the ---. the ---, if selected, is parsed as blank when written to the database. Thus, "---" is just DBMan's way of visualizing a blank or empty select field option.

So to correct the problem, I need to prevent db.cgi from parsing 0 to null or blank. Then I can turn on my required fields again.

Thanks,
beetleman

Marcus L. Griswold

well, if you look at the sub validate_record routine, you will see that all it does is return an error msg or the value OK. If the field is a required field, then it will return an error if the field had no data entered or if the entered data is just spaces. Anything else returns OK. So a 0 (zero) or "---" would return OK. See the line in the foreach loop that reads

if ($in{$col} =~ /^\s*$/) { # entry is null or only whitespace

So let's take a look at the sub add_record, specifically the line starting with if ($status eq "ok") {. Reading further, the database is then opened and the data is "printed" to the file using the sub join_encode routine. The data in the fields are untouched prior to the sub join_encode routine. This sub loops thru the fields and does a little clean up work - removing leading/trailing spaces, replacing newline characters, adding the delimiter, etc. Nothing unusual there.

So, what does that tell us? Well, if the add process basically takes the data but makes no changes, then we have to look elsewhere for the problem.

I do not see anything in the code that would replace a 0 with blank. While I primarily use Links 2, the code between the two are the same about 90% of the time (dbman has permissions and links 2 has categories and tracks hits). And links has several fields that default to 0 during the add process and they are not changed to blank. And as I read the dbman code, I don't see that happening there either.

So, the question is how is the field set to 0 by dbman? What does the html code look like for the add page? What does the default.cfg look like for the %db_def or %db_select_fields sections.

Unless the code to add the record has been changed, there is no way for it to replace a 0 or "---" with a blank.


Gene
"The older I get, the more I admire competence, just simple competence in any field from adultery to zoology."

I wrote

So, the question is how is the field set to 0 by dbman?

A better way to say that is:

How have YOU set the field to 0 to begin with?

Gene
"The older I get, the more I admire competence, just simple competence in any field from adultery to zoology."

Okay, the problem lies somewhere inside of the db.cgi. I copied an unmodified copy of db.cgi onto the server and the problems with zero disappeared

So the good news is that the problem with the zeros has been narrowed down to an error in db.cgi.
The bad news is that db.cgi has over 1200 lines of code to sift through and all modifications need to be put back in but...

When I try to add a record now with the original db.cgi, on submit, I am redirected to the login screen of the default database.!?@#$$%

Any thoughts?

Thanks,
beetleman

Marcus L. Griswold

well, I'm not convinced it is the db.cgi file. it could be in the html.pl file. Or even the default.cfg. I doubt that the add_record routine in db.cgi is causing the problem. I don't believe an original db.cgi does what you are experiencing. I doubt that any MODs to the add_record routine would be constructed so as to replace a zero with a blank. Maybe an error in applying a MOD could be a problem. But see the discussion on the substite function below because that is what would be required.

Have you applied any MODs to the add_record routine? Other routines called by the add_record routine and before the database is closed during the add process are the join_encode routine which does change the data and the validate_record routine which does not change the data. But look at them both. I do hope you indicate when a section has been changed from the original.

You would be looking for something like s,0, ,g; or s,0,&nbsp,g; ( if my perl is correct and I am not expert on that ). this is a substitute function in perl and would substitute a space for a 0.

The add_record routine is only 45 lines long, the join_encode only about 15 lines and the validate_record only about 45 lines long.

If all else fails, I would compare the good code with the "bad code." Here's what I do. Open up Word or a word processor that you can create a table. Set the page margins to .25 or .5 all the way around. Open a new document and create a two column, one row table. In Word 2000 and above you will need to turn off the Automatically resize to fit contents option by going to the Table, Properties, Option. From an unmodified dbman db.cgi file, find the add_record routine and copy the code and paste it into column one. Copy the same routine from your current live db.cgi file into the second column.

Now compare the two columns character by character, line by line. If you haven't made any changes to this routine in your live db.cgi, they should line up. As you go further down the page, you may need to move a line down in one column to get the corresponding lines to align across from each other.

Do the same for the join_encode and the validate_record routines.

If there are no differences or none that would explain your problem, open your browser and go to the add page. Find a field that should have a zero. Do you see a zero in the field? There should be a zero there. View the source code. If it is an INPUT statement, you should see something like VALUE="0" as part of the INPUT statement.

If all else fails, post the three add routines mentioned above. Or maybe a link to a page that will show the db.cgi. and the source code to a live add page.






Gene
"The older I get, the more I admire competence, just simple competence in any field from adultery to zoology."

Okay, The mod that gives me problems id the File Upload 2 Mod.

The original sub parse_form is replaced in the mod.
This leads me to believe that the problem lies there because the script is parsing 0 as a blank.

I highlighted a suspect problem below:


After commenting out all signs of the Mod, the database works fine.

So, I guess I'll have to try to figure out what is going on with the mod.

I'd direct you to the url if I could, I am running apache, perl, and all relevent webware on my home computer. While I have a static IP address, I won't give it out as my "server" setup isn't very secure. Cheaper and easier to setup a new site on my own computer.

I'm going to start a new thread concerning the File Upload 2 Mod and the zero problem.

Please feel free to reply here or in the new thread.

Thanks for the help.
beetleman

Marcus L. Griswold

As this thread seemed to wonder out of its original question, I started a new thread here:
File Upload 2 Mod killed my zeros.

Hope this will help keep the thread on topic.

Thanks,
beetleman

Marcus L. Griswold