Unable to iinsert into nuke_user error

Hangin' Around Joined: Aug 29, 2006 Posts: 29

Hi all

I have been having nothing but troubles installing raven nuke but after alot of google grease and coffee I have got most of it sorted out. I will admit I am a total beginner however I am not one to give up easily.

I have managed to install all the tables you shipped with rwsRavenNuke76_v2.02.02_FULL and got as far as the setup.php I then fill in all the data required in the form and press update and then nothing happens. I had a closer look and at the bottom of the page I found this error

Quote:

Unable to Insert into nuke_users table. MySQL reported: Field 'bio' doesn't have a default value
INSERT INTO nuke_users (user_avatar, user_regdate, username, user_email, user_password) values('blank.gif', 'Aug 29, 2006', 'warren','warren@nab-systems.com','8dd31a97c47f7298ee358955c3421a74')

Could some one please tell me what it means. Embarassed

Thanks in advance Warz

Posted: Tue Aug 29, 2006 6:18 pm

During installation of Ravennuke the installSQL.php program calls RN76_core_pl23.sql in the /sql directory. That should load a field called bio into the users table as tinytext. It has no default value (you can see that in the .sql file mentioned). Then setup updates the five fields you have listed (user_avator, user_regdate, username, user_email and user_password) based on what you input in the setup form.

You will be delighted to hear that I have no idea why the field 'bio' error message occurs. All I can think of is that maybe there has been some upgrade to your version of MYSQL and it now requires a default value for tinytext fields whereas previously it didn't. But that's pure conjecture.

Can you view your users table in phpmyadmin? Are all the fields there? If you look at what was loaded thru the RN76_core_pl23.sql program does it correspond with what's in phpmyadmin?

Posted: Wed Aug 30, 2006 1:21 am

Thank you fkelly for your fast responce to my problem however after a few more hour of google greese I managed to fix the problem or at least I hope so I went into the DB and manually change the table from (not Null) to null and it loaded then I noticed that the ublock was also giving a error so I did the same I am glad to have it all working now. Wink

Installed on my pc I have Windows XP Pro SP2; Apache 2.0.52 webserver; MySQL 5.0.24 and PHP 5.1.4. for the rest it is all standard

I have a list of thing that I had to change inorder to get this to work so it it is ok with you guys I would like to put a HowTO together for you, since the one that was shiped with the download (rwsRavenNuke76_v2.02.02_FULL ) was less than helpful and rather confusing to say the least.

I understand that most of you guys here Know all this well and the setups and all but again there are alot of guys like myself who just dont know enough about this.

Anyway Thanks again Warz_NL Very Happy

Posted: Wed Aug 30, 2006 1:59 am

warz_nl Please send me your list so I can investigate further.

Posted: Wed Aug 30, 2006 6:50 am

Guardian2003 wrote:

warz_nl Please send me your list so I can investigate further.

Sure thing I have sent you a pm Wink

Posted: Wed Aug 30, 2006 7:26 am

Glad you fixed your problem Warz. It's puzzling to me why it happened though and I will note it for the record here. The default "setup" for that field -- bio -- is NOT NULL. The installSQL does not put any value into it when the table is created. I am looking right at the distribution files when I say that. I also looked at phpmyadmin on my test system and that's the way the field is (not null with nothing in it). So why setup is giving you problems with it is beyond me.

What version of MYSQL are you using and what version of PHP? It would help us to know that.

Posted: Wed Aug 30, 2006 9:03 am

fkelly wrote:

What version of MYSQL are you using and what version of PHP? It would help us to know that.

I am running
MySQL 5.0.24
PHP 5.1.4

I hope this helps Wink

Posted: Wed Aug 30, 2006 9:44 am

Quote:

I am running
MySQL 5.0.24
PHP 5.1.4

Just be aware that RavenNuke is not certified to run in the posted environment...

Posted: Wed Aug 30, 2006 12:03 pm

Both the 'bio' and 'ublock' field do this on MySQL 5.
To fix it, run this in phpMyAdmin

Code:




ALTER TABLE `nuke_users` CHANGE `bio` `bio` TINYTEXT NULL DEFAULT NULL; 


ALTER TABLE `nuke_users` CHANGE `ublock` `ublock` TINYTEXT NULL DEFAULT NULL;

I recommend fixing this in the nuke.sql

Posted: Wed Aug 30, 2006 12:16 pm

Thanks Evaders. I was wondering if it was a version issue but I don't have any experience with MYSQL 5. I'll make sure it gets into Mantis if you haven't already.

Posted: Wed Aug 30, 2006 3:38 pm

Guys thanks again for your speedy replies.

To Montego
Hi; yes I am aware that this version is not certified for my current setup however I had started off using plain old phpbb2 which was fine until a friend of mine recommended RavenNuke to as a portal saying that you guys have the best and most secure all-in-one hands down. I just hope this information I supplied with my error I found using my current setup up can help you with future developement. Cool

To evaders99
Hi; to give you a quick answer I did then change but I login into phpMYadmin and edited the 2 tables inside the nuke_users I did mention this abit further up in one of my earlier post. As for editing the nuke.sql file I am like I said a total noob and would proberly mess it up. Thanks for the code though I will copy them and put them in a safe place until I know abit more on how to put them into the .sql file with out messing it up. Cool

Ok now for a new question what should I be using with my current setup?
and I have a extra server laying here with nothing on it except Win 2k3 is it possible to put this on there?

Thanks Warz_NL

Posted: Thu Aug 31, 2006 10:48 am

Well I don't really recommend a Windows server. It tends to be harder to manage scripts, even with Apache

Posted: Fri Sep 01, 2006 7:57 am

evaders99 wrote:

Both the 'bio' and 'ublock' field do this on MySQL 5.
To fix it, run this in phpMyAdmin

Code:




ALTER TABLE `nuke_users` CHANGE `bio` `bio` TINYTEXT NULL DEFAULT NULL; 


ALTER TABLE `nuke_users` CHANGE `ublock` `ublock` TINYTEXT NULL DEFAULT NULL;

I recommend fixing this in the nuke.sql

Evaders, are you recommending this core nuke sql fix for RavenNuke? I.e., will it work with lower versions of MySQL?

Posted: Fri Sep 01, 2006 6:38 pm

I've spent some time looking thru the MYSQL documentation online. It says that text and blob fields can't have default values and at first I thought that might apply to tinytext also. But I can't find anything specific about tinytext and default values. I also can't find anything about how it might have changes to that what would work for bio in version 4 wouldn't work in Version 5.

I've gone into PHPmyadmin in Raven's hosting and inserted a test field with tinytext set to null and a default value of null and it works. This is MYSQL 4.1.21. However, phpmyadmin also let me insert a text field with a default value of null where the documentation says that text fields can't have a default value. The field shows up in the table structure listing too.

This is puzzling to me. I would sure feel a lot better about having the rn76_core_pl32.sql file changed if we could find something definitive in the MYSQL changelog or documentation. At the very least if we make these changes we should regression test against several versions of MYSQL.

For what it's worth I just did a search on the whole sql directory in the RN2.10 distribution from the SVN and tinytext only shows up the two times that Evaders mentions.

Posted: Sat Sep 02, 2006 3:16 am

Whilst I wouldn't want to disagree with those who are far more competent than me, but if the table field is set to NOT NULL then I have to question whether the sql file is correct, surely it should be inserting *something*.

Any way that a bit moot, I'm concerned why the sql works perfectly well for mysql 4.1.x and not for 5.x.x in this instance as my local box is using 5.0.21 and I have not had this issue.

Posted: Sat Sep 02, 2006 6:50 am

Funny how great minds think alike Guardian. I was lying awake last night with a queasy feeling about this. If MYSQL had changed something in the treatment of tinytext fields between versions I would expect to find some reference to it in the documentation. Plus WARZ couldn't be the only one running MYSQL 5 so how come he is the only one that has reported this error?

This morning I started looking at setup.php from both the 2.02 and the upcoming 2.10 distributions. Here is the relevant section from 2.02:

Code:

   // Posting data to nuke_users table


   $sql = "INSERT INTO nuke_users (user_avatar, user_regdate, username, user_email, user_password) values('$users_user_avatar', '$users_user_regdate', '".mysql_escape_string($users_username)."','$users_user_email','".md5($users_user_password)."')";


   $rc = @mysql_query($sql);


   if (!$rc) die('Unable to Insert into nuke_users table. MySQL reported: '.mysql_error()."<br />$sql");

However in 2.10 Raven chose to truncate the table first and then insert a full new record before inserting the 5 fields he inserts in 2.02. Here's that code:

Code:

   $sql = 'TRUNCATE TABLE '.$prefix.'_users';


   $rc = @mysql_query($sql);


   if (!$rc) die('Unable to truncate '.$prefix.'_users table. MySQL reported: '.mysql_error());


   if ($debug) echo '<s_cript type=\'text/javascript\'>alert(\''.$prefix.'_users table truncated\');</s_cript>';


   $sql = "INSERT INTO ".$prefix."_users VALUES (1, '', 'Anonymous', '', '', '', 'blank.gif', 'Nov 10, 2000', '', '', '', '', '', 0, 0, '', '', '', '', 10, '', 0, 0, 0, '', 0, '', '', 4096, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 10, NULL, 'english', 'D M d, Y g:i a', 0, 0, 0, NULL, 1, 1, 1, 1, 1, 1, 1, 1, 0, 3, NULL, NULL, NULL, 0, 0, 0, 0)";


   $rc = @mysql_query($sql);


   if (!$rc) die('Unable to Insert into '.$prefix.'_users table. MySQL reported: '.mysql_error()."<br />$sql");


   $sql = "INSERT INTO ".$prefix."_users (user_avatar, user_regdate, username, user_email, user_password) values('$users_user_avatar', '$users_user_regdate', '".mysql_escape_string($users_username)."','$users_user_email','".md5($users_user_password)."')";


   $rc = @mysql_query($sql);

Changes in this area tend to be in Raven's bailiwick anyway and he doesn't make changes like this without a reason so I think can safely "punt" this to him.

The one other thing that I can find in the documentation is that there is a "strict" server mode for MYSQL that is apparently more persnickety about errors with default values and I'm wondering if maybe that's "on" in Warz's case but not in most of the rest of our cases.

Posted: Sat Sep 02, 2006 7:31 am

It's sounding like the server config then.
I'll see if I can find the 'strict' switch on my local box as if this is a problem, I need to be testing in that environment.

Posted: Sat Sep 02, 2006 10:59 am

I believe Raven added that truncate to the code to fix the problem of duplicate users being added if someone runs the setup.php more than once. That is all. Therefore, more research is definitely in order and sounds like you guys are "on the trail"...

Posted: Sat Sep 02, 2006 5:05 pm

In my Ravennuke test system I just replicated a simplified version of the rn76_core_pl32 file for the users table but just using a few fields including bio as it's defined there now (`bio` tinytext NOT NULL). Then I did an insert that simulated the setup.php process that currently is in the 2.10 build. I did this all by copying the SQL into phpmyadmin. No problems. My next step was going to be to try it with strict mode on but when I went into the documentation I found out that strict mode had been added as of MYSQL 5. So I couldn't access it in MYSQL 4.1.2.

What I'm thinking now is that WARZ maybe has a MYSQL 5 system with strict mode on and it's kicking out these errors. Here's the SQL that I was using:

Code:

CREATE TABLE IF NOT EXISTS `xxx_usersxxx` ( `user_id` int(11) NOT NULL auto_increment, `name` varchar(60) NOT NULL default '', `username` varchar(25) NOT NULL default '',  `bio` tinytext NOT NULL, PRIMARY KEY  (`user_id`), KEY `uname` (`username`)) ) TYPE=MyISAM;

This created a table that doesn't interfere with normal Nuke operations and includes one tinytext field.

Then I copied this into phpmyadmin and ran it:

Code:

INSERT INTO xxx_usersxxx (user_id, name, username) values(1, 'frank', 'frank kelly');

Next I was going to delete that record and insert the same record except with strict mode on, but I don't have the ability to do that. Maybe Guardian can try that ... or come up with a better way to test it? Raven is going to look into this for the next release but I sure would like to get a good handle on where this problem came from and be able to have it posted here too.

Posted: Wed Sep 06, 2006 11:55 am

Well you guys are great however most of this is french to me Embarassed

However if you guys would like me to do anything to help plz just ask I am luckily a fast learner and find this all very interesting.

I am alsogoingto reinstall MySQL 5.0.24 and look for the strict switch and see if I cant disable it then rerun the raven-nuke setup. I will let you all know what happens Wink

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

evaders99 wrote:

Both the 'bio' and 'ublock' field do this on MySQL 5.
To fix it, run this in phpMyAdmin

Code:




ALTER TABLE `nuke_users` CHANGE `bio` `bio` TINYTEXT NULL DEFAULT NULL; 


ALTER TABLE `nuke_users` CHANGE `ublock` `ublock` TINYTEXT NULL DEFAULT NULL;

I recommend fixing this in the nuke.sql

I have made this change for v2.10.00.

Posted: Tue Sep 12, 2006 6:46 am

Thanks Raven Wink

When is 2.10.00 going to be released I would like to get that one installed on my system and get a head start Very Happy

I suppose I will have to be patient Rolling Eyes

Later guys