TYPO3 Core

Hi
this could be the same bug as the one i reported (0004939).
Try the patch i provided (on own risk) and i think the error will be gone

cya

Hi Christian,

u r right. After using your patch it is fine. Get no longer an SQL error.
Hope this is fixed in the next RC.

cu

Frank, your patch works of course. But I doesn't solve the error it just suppresses the output. The more interesting thing would be, which SQL query produced the error.
So, please revert the applied patch as provided in bug-id #16952. Go to the install tool, choose "5: All configuration" and enable the sqlDebug. After that try again to edit BE users to reproduce the error and tell us the faulty SQL queries that will be shown. Thanks!

okay i tried the debuging and it looks like this:

The first error looks like this:

caller: t3lib_DB::exec_SELECTquery
ERROR: Lost connection to MySQL server during query
debug_backtrace: SC_mod_tools_dbint_index->main // SC_mod_tools_dbint_index->func_records // t3lib_admin->lostRecords // t3lib_DB->exec_SELECTquery // t3lib_DB->debug

All the following look like this:

caller: t3lib_DB::exec_SELECTquery
ERROR: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)
debug_backtrace: SC_mod_tools_dbint_index->main // SC_mod_tools_dbint_index->func_records // t3lib_admin->lostRecords // t3lib_DB->exec_SELECTquery // t3lib_DB->debug

The SQL Query seems to be irrelevant because it happens on all tables...
Seems to me that the skript wants to reach the database through a socket and not via tcp?!?

If you need some query's i'll post some

cya

hm... i'm confused. i tried and sql statement in phpmyadmin. the database (mysql 5.0.22) answered "#2013 - Lost connection to MySQL server during query"

the query was:

SELECT uid,pid,username
FROM be_users
WHERE
pid NOT IN (-1,0,82,127,106,81,1,105,94,88,9,84,114,113,85,26,25,122,126,125,124,
123,24,23,99,100,101,102,103,104,22,10,20,19,18,120,8,28,33,32,31,
30,97,129,27,98,35,34,29,17,96,15,14,13,12,6,7,37,42,43,41,40,39,38,
36,52,118,51,50,49,48,47,46,45,44,107,108,109,110,119,5,57,56,128,
55,54,53,130,4,68,59,66,67,89,64,65,95,61,90,62,63,3,72,71,2,92,91,
73,21,11)

[EDIT] After some trys: the "-1" in the beginning of the id list is the problem. without the "-1" the query work perfectly, witch make sense since the field "pid" is unsigned.

Hi Christian and Oliver,

i rolled back the original class and enabled sql debug .

Here is the output of the sql debug:

caller t3lib_DB::exec_SELECTquery
ERROR Table 'renaultclub.sys_history' doesn't exist
lastBuiltQuery SELECT tstamp
FROM sys_history
WHERE
tablename='be_users' AND recuid=2
ORDER BY tstamp DESC
LIMIT 1
debug_backtrace SC_alt_doc->main // SC_alt_doc->makeButtonPanel // t3lib_DB->exec_SELECTquery // t3lib_DB->debug

I tried it in phpmyadmin and the table dosn't exists.

me again...

i located the "-1".
In "typo3/sysext/lowlevel/dbint/index.php:456" the the var $id_list is set. It starts with "-1,0.....". I removed the "-1" (cause it doesn't make sense in my opinion) and now i don't get errors.

@ Oliver: Is this a "real" fix? Is the "-1" good for something?

Christian, you're right... the pid of be_users is defined as unsigned. The pid of a table gets "-1" if the accordant record is handled for workspaces or versioning. But be_users cannot be versionized at all.
So first possibility would be to remove the unsigned from the SQL definition, the second one would be to localized the call to the database causing the "-1" and remove it for be_users, etc.

You mentioned "The SQL Query seems to be irrelevant because it happens on all tables...". Please tell on which other tables this happened. Really "all" (e.g tt_content, pages, etc.) or only those you tested?

@Frank: Please go to your install tool, "2: Database analyzer", "Update required tables" and click "COMPARE" - the should be shown some tables you have to correct on your TYPO3 installation.

@Christian: The removal of "-1,0" only fixes the problem if you do not use workspaces and versioning as mentioned in my previous note. This would cause other problems for users that need these features. I think a reasonable and easy solution could be remove "unsigned" from SQL table definitions in t3lib/stddb/tables.sql

@Michael Stucki: Could you please support me on this issue? Thanks! :-)

hi
these are the affected tablese. the intresting thing is, that also eg "tt_content" is affected. but the pid is NOT unsigned there. could it be, that the conection breaks because of the first error and all the other queries won't work because of the broken connection?

be_users
be_groups
sys_filemounts
sys_workspace
sys_language
tt_content
fe_users
fe_groups
sys_domain
pages_language_overlay
sys_template
static_template
tt_news
tt_news_cat
tx_bahagphotogallery_galleries
tx_bahagphotogallery_images
tx_irfaq_q
tx_irfaq_cat
tx_irfaq_expert
tx_rtehtmlarea_acronym
pages

Please see the attached file sql_0004951.patch with should solve the problem.
ATTENTION: Please make sure that you make a backup of your database before applying the patch, it changes SQL definitions and may cause damage to your data. Just to be secure, make a database backup!

The patch removes all occurrence of "unsigned" in SQL definition files.
I could not reproduce this error using MySQL 5.0.32/Debian, but it might occur for older releases e.g. also used by webhosting providers.

It is a bug of MySQL until 5.0.22 and was solved in 5.0.23/5.0.24 (see bug-report http://bugs.mysql.com/bug.php?id=19618). However, TYPO3 could/should handle this issue.
So, the patch file I attached possibly doesn't fix this problem for MySQL 5.0.22!

"I could not reproduce this error using MySQL 5.0.32/Debian"

ahhh i knew i should do some updates.... i just updated from 5.0.22 to 5.0.32 and now i don't get any error!

thanks for your support!!!!

Hi,

after i did a compare i saw that there was db table left.

CREATE TABLE sys_history (
uid int(11) unsigned NOT NULL auto_increment,
sys_log_uid int(11) NOT NULL default '0',
history_data mediumtext NOT NULL,
fieldlist text NOT NULL,
recuid int(11) NOT NULL default '0',
tablename varchar(40) NOT NULL default '',
tstamp int(11) NOT NULL default '0',
history_files mediumtext NOT NULL,
snapshot tinyint(4) NOT NULL default '0',
PRIMARY KEY (uid),
KEY recordident (tablename,recuid,tstamp),
KEY sys_log_uid (sys_log_uid)
);

No i get no error editing the user.
Thank you very much for your support.

Frank, great!
So this bug could be closed. The thing with "unsigned" definitions in SQL are tweak but should also be handled.

I'll take care of fixing the query in dbint

Attached is a patch that should fix the problem. Please check and let me know.

Fixed in TYPO3 4.1RC2