Hello,

I'm having a little problem with DBMan and I was wondering if anyone might be able to help me.

I've finished most of the installation and I've had no problems. Much to my surprise (and delight) I went without a single error for quite some time.

Before finding DBMan I maintained a database manually, and I decided to move all of the listings from my old database into DBMan, so I inputed the listings one by one using the add record form. I went through about 52 listings without any problems, and then all of a sudden I got a 500 Internal Server Error and my error logs don't tell me anything except "Premature end of script headers."

This baffles me because I didn't do anything to change db.cgi, default.cfg or html.pl between submitting one record successfully and trying it again and receiving the error. And everything else in the script works just fine.

Does anyone have any idea how one aspect of a script could just suddently stop working? I turned on the debug feature in the default.cfg file and received this message when I tried to add a record:

CGI ERROR
==========================================
Error Message : Debug Information
Script Location : db.cgi
Perl Version : 5.00502
Setup File : default.cfg
User ID : admin
Session ID : admin.93009330976285

Form Variables
-------------------------------------------
EMail : test@test.com
ID : 52
Location : Alabama
Looking_For : this is a test
Name : test
Religion : Catholic
Self_Description : this is a test
Userid : admin
add_record : Add Record
db : default
uid : admin.93009330976285

Environment Variables
-------------------------------------------
CONTENT_LENGTH : 186
CONTENT_TYPE : application/x-www-form-urlencoded
DOCUMENT_ROOT : /www/survivalnetwork
GATEWAY_INTERFACE : CGI/1.1
HTTP_ACCEPT : application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
HTTP_ACCEPT_ENCODING: gzip, deflate
HTTP_ACCEPT_LANGUAGE: en-us
HTTP_CONNECTION : Keep-Alive
HTTP_HOST : www.survivalnetwork.org
HTTP_REFERER : http://www.survivalnetwork.org/cgi-bin/dbman/db.cgi?db=default&uid=admin.93009330976285&add_form=1
HTTP_USER_AGENT : Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; CNETHomeBuild03171999; DigExt)
PATH : /usr/local/bin:/usr/bin:/bin:/usr/local/mysql/bin
QUERY_STRING :
REMOTE_ADDR : 38.11.102.42
REMOTE_HOST : ip42.new-haven.ct.pub-ip.psi.net
REMOTE_PORT : 2952
REQUEST_METHOD : POST
REQUEST_URI : /cgi-bin/dbman/db.cgi
SCRIPT_FILENAME : /www/survivalnetwork/cgi-bin/dbman/db.cgi
SCRIPT_NAME : /cgi-bin/dbman/db.cgi
SERVER_ADMIN : webmaster@survivalnetwork.org
SERVER_NAME : survivalnetwork.org
SERVER_PORT : 80
SERVER_PROTOCOL : HTTP/1.1
SERVER_SOFTWARE : Apache/1.3.6 (Unix) mod_ssl/2.2.6 OpenSSL/0.9.2b PHP/3.0.7


This message doesn't help me to understand what the problem might be and how I might fix it, so does anyone know what might be going on?

Any information would be greatly appreciated.

Thanks in advance,
Peter

My guess is that there's a problem with your .count file. Do you have $db_key_track set to 1?



------------------
JPD

This is Peter again. I just figured out what the problem was when I examined the db.cgi file.

I wanted to have the ID key automatically move to the next available number, but I wasn't sure how to do so, so I experimented and something I tried worked. I put the "value" of the ID field as "1" which I knew was already taken. So, because I set $db_key_track to 1, it would automatically check for the next available ID number and use that one. But, when I examined the db.cgi file I saw that it would only check for the next available ID number up to 50, and then it would give up, which is why I got the 500 Internal Server Error. I'm not sure how I managed to get to 52 before I started getting the error, but somehow I did.

In any case, I just edited the script to keep checking for the next available ID number up to a larger number (I have it set at 100 now, but I'll probably change it to something like 1000 later).

I still have one question, though. Is this is a safe way to have the script automatically use the next available ID key? After reading some of the other posts here I see that there's another way to do this (which, I guess, is the way I was supposed to do it), so I'm wondering if I should try to reconfigure the script to do it that way, or just keep doing what I'm doing now.

Thanks,
Peter

Well, you sorta understood it correctly, but not quite. This is the process the script goes through when you have the $db_key track set to 1 and the data type of your key field is "numer."

When you go to the add form, there's a command

&html_record_form (&get_defaults);

This command causes the script to first go to a subroutine in db.cgi, which will get the default values you have set for the database, as well as your key value. Here's part of that subroutine:


This code looks at the .count file, reads the value and adds 1 to it. It then gets the other default values you have set for your fields and sends them back to sub html_add_form. The values are then filled in the html_record_form, and the user can then fill in the rest.

When the user clicks the "Add Record" button, the script goes to sub add_record in db.cgi. The first thing the script does is to make sure the values are within acceptable ranges, including making sure that the key is not a duplicate.

It goes through all of the current records in the database and, if it finds a key with the current value, it sends back a message "duplicate key error."

Back in sub add_record, if it has been given the "duplicate key error" message, it tries a new key value. It is set up to only try 50 times.


After 50 tries, you should get the add failure form, with a "duplicate key error" message. But, if you've set things up correctly, you ought not to get that at all, because after a record is added, the script updates the counter file:


This is how it's supposed to work. For some reason, you database isn't working correctly, though. We need to figure out why.

Look in your .db file and see what the last key value is. Then open your .count file and see what is in there. They should match. If they don't, change the .count file to match the key value of the last record in your .db file.

Also, set the value in sub add_form back to 50.

Add another record. Then look at the .count file again. It should have been incremented by 1. If it wasn't, we'll need to work to find out why.


------------------
JPD

Thanks for the information. I'm still a bit confused, though, as I'm getting a "ID field cannot be left blank" error when I try to add a listing without manually adding an ID.

IDs were being automatically generated before when I had the VALUE of my ID field set to "1" in the add record form. But, when I set it back to what it originally was, "$rec{'ID'}", I get the "ID field cannot be left blank" error again. My .count file and .db file have the same ID number for the last record added, so I'm not sure what the problem could be.

I went into the db.cgi file and all the code snipetts you specified were there just as you had written them.

Should the "default" value or any other ID values in the .cfg file be set to anything specific?

Thanks again for your help. It's much appreciated.
-Peter

You do have $db_key_track = 1 in your .cfg file, don't you? Yes, you would since the .count file is being incremented.

When you go to the add form, is the ID field filled in?


------------------
JPD

Yes, my $db_key_track is set to one, but no, the user ID field is not filled in when I access the add record form. I had the ID field on the add record form set to "HIDDEN" before, but I've changed that to "TEXT." It's still not filled in, though. I take it that there should be a number in the ID field when I access the add record form and am entering my data?

Thanks again,
Peter

Yep. It should be there when you get to the add form. It's probably a good idea to have it as a visible text field for now until we get it straightened out. Then you can switch it back to a hidden field.

The next thing I can think of is that there is a problem with the field name. Check to make sure that the name in the db_def part of the .cfg file, the $db_key setting in the .cfg file and the references to the field in sub html_record_form are all the same. You referred to $rec{'ID'}, so I'm assuming that your field name is 'ID'. Make sure that your text field includes

name="ID" value="$rec{'ID'}"

your $db_key='ID'; and the field definition is listed as 'ID'. Remember that case counts, so if any one of these is "id" or "Id" or "iD," this could be the cause of your problem.

You also mentioned

That may have been a typo. (I hope so!) Just to be sure, check to make certain you don't have the $auth_user_field set to the field number of the ID field. That could get really hairy!

(You're welcome. I'm glad to help. )

------------------
JPD

Well, I've rechecked my .cfg file and my html.pl file and all the key fields are named "ID" in caps. I also have $rec{'ID'} in all of the VALUE fields for the ID. So, everything looks alright in this department, but still no ID when I access the add record form. "Curiouser and curiouser..."

Thanks again,
Peter

P.S. Whoops! That was indeed a typo in my last posting. ;-) I meant to type "the ID field is not filled in." It was pretty late when I was writing that and I had been on the computer far too long. Guess I started dozing off :-)

Do you have any other default values going into the add form? If so, are they being added correctly?

It's possible that when you were editing your html_record_form that you eliminated the line:

my (%rec) = @_;

Check to make sure it's there. Also that your html_add_form has the command

&html_record_form (&get_defaults);



------------------
JPD

Aha! Now I see the problem. I had deleted the reference to &html_record_form (&get_defaults); and just filled in what I wanted for the add form. When I replaced the reference to &html_record_form (&get_defaults); everything worked properly. So, my only question now is--is there any way to customize the add form or the search form? Or do I always have to use the form I created in &html_record_form? Perhaps if I deleted the reference to &html_record_form in the search section and filled in my own search form?

Thanks for all your help,
Peter

If you want separate entry forms and search forms, here's what you do.

You will probably want fewer fields on your search form, so copy sub html_record_form and paste the whole thing just before your previous subroutine. You will now have to identical subroutines named "sub html_record_form."

Change the name of the second one to
sub html_search_form

Then go through and delete any fields you don't want on your search form.

Change

&html_record_form

to

&html_search_form

in the following subroutines:

html_view_search
html_view_failure
html_delete_search
html_modify_search



------------------
JPD