Welcome, Guest. Please login or register.
Did you miss your activation email?
September 16, 2014, 01:22:59 AM

Login with username, password and session length

Last 25 Topics



Note:  Clicking the link above will open a new tab in your browser !!

Recent

Members
Stats
  • Total Posts: 173913
  • Total Topics: 19846
  • Online Today: 50
  • Online Ever: 278
  • (October 31, 2012, 08:52:18 AM)
Users Online
Users: 0
Guests: 39
Total: 39

Donate

Help us to keep the support site
going, Please consider a small donation.

Thank you
Please read the Posting Guidelines

Author Topic: [bugtracker] database errors  (Read 1969 times)

0 Members and 1 Guest are viewing this topic.

Maxâ„¢

  • Guest
[bugtracker] database errors
« on: April 08, 2010, 03:04:17 AM »
getting errors after i create a new block and try to change it to other block types,  there is old topics about this for previous versions.

Code: [Select]
index.php?action=tpadmin
Database Error: Out of range value adjusted for column 'pos' at row 1

UPDATE smf_tp_blocks SET pos = 130 WHERE id = 22
Apply Filter: Only show the errors from this file
File: Sources/TPortalAdmin.php
Line: 2260

Code: [Select]
?action=tpadmin
Database Error: Incorrect integer value: '' for column 'var3' at row 1

UPDATE smf_tp_blocks SET var3 = '' WHERE id = 28
File: Sources/TPortalAdmin.php
Line: 2371

Offline bloc

  • Don't wake the bear
  • Developer
  • *
  • Posts: 4788
    • Blocthemes
Re: [bugtracker] database errors
« Reply #1 on: April 08, 2010, 01:44:18 PM »
Which blocktype did you change from - and to what type?

Max

  • Guest
Re: [bugtracker] database errors
« Reply #2 on: April 08, 2010, 03:18:41 PM »
It happens when you add a new block, leaving the title field empty clicking save, when you go back to tp admin blocks section, the block that has "-no title-".  when you try changing the Type to something else, the Database Error: Out of range value adjusted for column 'pos' shows and when you try changing the name of "-no title-" to something else, it saves the name fine but the same error shows.
« Last Edit: April 08, 2010, 03:20:14 PM by Maxâ„¢ »

Offline bloc

  • Don't wake the bear
  • Developer
  • *
  • Posts: 4788
    • Blocthemes
Re: [bugtracker] database errors
« Reply #3 on: April 09, 2010, 01:45:44 AM »
I cannot reproduce this, so I am thinking something in database isn't updated from beta4. Possibly the "pos" column in articles table, which should be a INT NOT NULL type.

Max

  • Guest
Re: [bugtracker] database errors
« Reply #4 on: April 09, 2010, 04:42:03 PM »
fixed it in the database to INIT default none
 - it worked fine afterwards.

its same so for article categorys.. when you go and create a blank category and click submit, a similar database errors shows up.

Code: [Select]
Database Error: Incorrect integer value: '' for column 'subtype2' at row 1
INSERT INTO smf_tp_variables
(value1, value2, value3, type ,value4, value5, subtype,value7, value8, subtype2, value9)
VALUES('','0','','category','',0,'','',0,'','')
File: Sources/TPortalAdmin.php
Line: 2044

changed the subtype2 to TinyText Null and it sorted that error also.  :)

Offline bloc

  • Don't wake the bear
  • Developer
  • *
  • Posts: 4788
    • Blocthemes
Re: [bugtracker] database errors
« Reply #5 on: April 20, 2010, 11:24:51 AM »
Changing it to TinyTEXT is actually wrong, it should be INT, but the code should have supplied a 0 in the call.

These are both fixed for TP v1.0 beta5.2.

CERDIP2

  • Guest
Re: [bugtracker] database errors -Alternate Fix
« Reply #6 on: August 27, 2010, 01:16:34 PM »
I had the same problem with creating an article category, using TP v1.0 beta5.2 with SMF 2 RC3.

I found that the VALUES parameters in the query were slightly out of sequence (doesn't take much :-)

So take this from ln# 2051 of sources\TPortalAdmin.php:
Code: [Select]
VALUES('" . strip_tags($name) . "','".$parent."','','category','',0,'','',0,'','')", __FILE__, __LINE__);
and change it to this:
Code: [Select]
VALUES('" . strip_tags($name) . "','".$parent."','','category','',0,'','','',0,'')", __FILE__, __LINE__);
and now it works, no mucking with db tables & such :-)
« Last Edit: August 27, 2010, 02:52:37 PM by CERDIP2 »