Project

General

Profile

Actions

Bug #16946

closed

SQL error with Templavoila/DBAL/PostgreSQL: Different language

Added by Mathias Behrle over 17 years ago. Updated about 14 years ago.

Status:
Closed
Priority:
Should have
Category:
Database API (Doctrine DBAL)
Target version:
-
Start date:
2007-02-06
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

While implementing the merrychristmas example website in Postgres environment, there occur several SQL errors. Hopefully this is the right pace to do so and not in Templavoila, please redirect it, if one or the other error should be caused by Templavoila itself.

After adding different website translations the preview result is:
TemplaVoila ERROR:
Template Object could not be unserialized successfully.
Are you sure you saved mapping information into Template Object with UID "2"?

There are two SQL-related errors, the log joined in a seperate file due to its dimension (see attached file).

The default language is shown without problems in the FE.

typo3-dev 4.1 (svn rev 1964)
postgresql 8.1.4-6~bpo.1
apache2 2.0.54-5sarge1
php5 5.2.0-7~bpo.1

Firefox/Iceweasel/2.0.0.1
(issue imported from #M4931)


Files

sqlerror_view_lang.txt (49.5 KB) sqlerror_view_lang.txt Administrator Admin, 2007-02-06 16:53
class.tx_templavoila_htmlmarkup.php.patch (1.06 KB) class.tx_templavoila_htmlmarkup.php.patch Administrator Admin, 2007-02-09 21:22
Actions #1

Updated by Mathias Behrle over 17 years ago

Tarcking down the first SQL-error (invalid input syntax for type bytea) I come to the following results:
- the input error is due to double backslash(es) in the input
- the original input providing the backslashes are lines 1479 and 1485 of /typo3/sysext/css_styled_content/static/setup.txt:
/* Hide from IE5-mac. Only IE-win sees this. \*/
Since I suppose the backslashes are simply needless, I removed them and for this case it can serve as a workaround.
- if I understand correctly http://www.postgresql.org/docs/8.2/interactive/datatype-binary.html, the input of a backslash should not be simple escaped, but double escaped. At least the input of '\\\\' is working and shows up in a SELECT as \\, which can be retranslated to a simple backslash while the input of a simple backslash just escapes the following character.

class.ux_t3lib_db.php says for function exec_INSERTquery:
Field values as key=>value pairs. Values will be escaped internally. Typically you would fill an array like "$insertFields" with 'fieldname'=>'value' and pass it to this function as argument.

So this internal escape seems not to be adequate for PostgreSQL bytea.

Actions #2

Updated by Mathias Behrle over 17 years ago

The second error:
zero-length delimited identifier at or near """" at character 89
SELECT * FROM "tx_templavoila_tmplobj" WHERE "parent" = 2 AND "rendertype" = "" AND "sys_language_uid" = 1 AND "tx_templavoila_tmplobj"."deleted" = 0 AND "tx_templavoila_tmplobj"."t3ver_state" != 1

For PostgreSQL the (empty) string delimiter has to be ' (single quotes), not " double quotes.

The query is coming from class.tx_templavoila_htmlmarkup.php, lines 699/703.

I couldn't manage to get the single quotes by inserting function fullQuoteStr, as proposed by class.ux_t3lib_db.php :
$GLOBALS['TYPO3_DB']->fullQuoteStr('parent='.intval($uid).' '.$where.$TSFE->sys_page->enableFields('tx_templavoila_tmplobj'),'tx_templavoila_tmplobj') returned double quotes "" => ""
or escaped the single quotes, so they appeared twice \'\' => ''''

Finally I had to stick to just replace the double quotes by single quotes (s. attached patch), now not knowing if this code will run in other DBMS as well or if it is a bug in function fullQuoteStr resp. adodb. So please redirect this bug adequately.

Actions #3

Updated by Karsten Dambekalns almost 17 years ago

The second error is a TV one, and is fixed as far as I know.

The usage of fullQuoteStr() as in ~12327 is wrong, it is used to quote one value, not an entire (part) of a SQL query.

Actions #4

Updated by Karsten Dambekalns almost 17 years ago

Regarding the escaping problem, please try again with the current SVN code. It has code to specifically deal with BLOB/CLOB fields.

Actions #5

Updated by Golo Meierhenrich about 14 years ago

Even if this posting is rather old I ran into the same issue using typo3 4.3.1, templavoila 1.4.1 and MS SQL Server via ODBC (with dbal 1.0.3 and adodb 5.10.0).
The attached patch fixes the issue for me as well (if the line numbers are updated). Maybe it's worth another look.

Actions #6

Updated by Xavier Perseguers about 14 years ago

Patch sent to mailing list typo3.teams.templavoila

Actions #7

Updated by Tolleiv Nietsch about 14 years ago

Committet to trunk (rev. 30801) and templavoila_1-4 (rev. 30802) - could someone please mark the issue as resolve/closed ? thx

Actions

Also available in: Atom PDF