I have just set up DBMan and everything was going well. I was making some changes to html.pl and then things went wrong. First the record added screen displayed nothing even though when I did a list all everything would appear OK.

I sorted that out but now I have one field where the result is displayed as "default". I put back in the ID field where I had taken it out and the problem has moved up one field. It was field 10 and it's now field 9 that shows the problem.

Any ideas would be greatly appreciated.

The URL where this can be seen is www.homes-from-home/cgi-bin/thenursery/db.cgi

Cheers,

------------------
Regards,

AJ

Aha!! It's only taken about 4 hours but I've sussed it.

Whatever I did, it was always position 10 that caused the problem.

I moved the userid back to 10 and the problem field to the bottom of the pile and it all works now.

I wouldn't mind knowing why though.

------------------
Regards,

AJ

Actually, it's field 9 that's giving you the problem. (Or was until you changed things.) Fields start counting from 0.

The reason you had the problem is that you hadn't changed the value of the $auth_user_field from the demo. You can put the Userid field in any position, but you have to change the $auth_user_field to match the number of the field.



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

Cheers for that. At least I know that I can play around now without messing it all up again. This has got to be the best free database script there is. It's amazingly powerful. The site I'm building is going to be a free resource for people to look for plants with characteristics they choose. I remember reading that this will work up to about 1 mb and then start to slow down. I reckon that gives me about 2500 plants. Should I split the database into trees, shrubs etc or is there another answer? I've got a horrible feeling that it's going to be SQL which I know nothing about.

------------------
Regards,

AJ

You are right. After the .db file reaches about 1M in size, things start to slow down appreciably. (Actually, that's just what I've heard. I've never had one get that big yet. )

You might want to think about splitting the database into different parts. The downside is that users would only be able to search in one database at a time. The upside is that you'd be able to have more records in your database.

If you're going to do this, it would be best to start with the separate databases than to try to split them later on. It would be possible, but a real pain.

I don't know anything about the SQL version either, really, except for the things it has in common with the regular version.

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

Cheers for that. I have thought about splitting into obvious categories but it looks complicated and I'm just trying to pluck up the courage to do it. I think that's what I'll go for though. Everything is new at the moment. It's a steep learning curve!



------------------
Regards,

AJ

I do understand, AJ. It is a steep learning curve. But there are very few feelings that are greater than finally figuring it out and having the script do what you want it to do. (I often scare my cats when I holler "YES!" at 3am. )


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

I know the feeling. My inlaws thought I was mad as I sit up until the small hours most nights playing with stuff like this. That was until I said that I achieve or learn something, or both, every single night. They'd rather sit and veg out in front of the TV. BTW: Just got multiple DBs working and it's only 10:36 pm

------------------
Regards,

AJ