Deprecated - Database compatibility

One of my favourite features besides the performance gain of prepared statements is that you can substitite any value with a '?'. This works great for null values, etc. So, here is a little hack I came up with when I nearly lost the plot working with PHP4. The regex could be a little more refined to only replace question marks where it should, but otherwise, it works.

It looks as if the 4.6 problem with MySQL 5 is occuring with 4.7.5. I get a similar error:

user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') AND n.status = 1 ORDER BY sticky DESC, created DESC LIMIT 5' a query: SELECT DISTINCT(n.nid), n.title, r.body, sticky, created FROM term_node t INNER JOIN node n ON t.nid = n.nid INNER JOIN node_revisions r ON r.vid = n.vid WHERE t.tid IN () AND n.status = 1 ORDER BY sticky DESC, created DESC LIMIT 5 in

Is there a PostgreSQL users development group, or one for other users besides MySQL?

I'm not really sure i am in the right forum again, please direct to the right one if I am wrong.

Hello, everyone!

Here is my route to upgrading the UTF-8 data stored in MySQL as latin1 to a utf8-based charset and collation.

First, a conversion shell script:

1  DBFROM=dp
2  DBTO=dp
3  LOGIN=dp
4  PASS=XXX
5  mysqldump  --extended-insert=FALSE --default-character-set=latin1  -u $LOGIN -p$PASS $DBFROM >dp.sql
6  cat dp.sql |sed  -e 's/DEFAULT CHARSET=latin1;/DEFAULT CHARSET=utf8 COLLATE utf8_bin;/'>dp2.sql
7  cat dp2.sql |sed  -e 's/SET NAMES latin1/SET NAMES utf8/'>dp3.sql
8  echo " drop database $DBTO; create database $DBTO character set utf8 collate utf8_bin;"|mysql -u $LOGIN -p$PASS
9  mysql -u $LOGIN -p$PASS $DBTO <dp3.sql

Let us go over the lines.

Lines 1-4 configure the connection options.

Line 5 dumps the contents of the database. The --default-character-set=latin1 option disables the recoding of the date to the current locale of the system. Since the MySQL considers your UTF-8 data to be in latin1, this may result in data corruption. We also set --extended-insert=FALSE to easily detect the errors.

Line 6 passes over the dump of the data and changes the declaration of the default charset to UTF-8. It also specifies the collation scheme to be utf8_bin. This is the trickiest point and it took me a couple of hours to figure it out. Your fake latin1 data uses the latin1_swedish_ci collation by default where ci stands for case-insensitive. If you dump your data with the latin1 charset and latin1_swedish_ci collation and try to insert with the UTF-8 charset and its default utf8_general_ci collation, you will likely get unique key contraint errors as MySQL will start to consider the cyrillic А to be equal to а, and the greek Ρ to be equal to ρ just and it earlier considered the latin A to be equal to a.

Following a serious problem with my database, I decided to reinstall drupal and to have a clean and empty database.
From a back-up, I populate the tables node, node_access, node_revision
Now I can access all my nodes but ...
It seems that the number of records are not updated because when I want to create a new node, drupal say "duplicate node". That means, I suppose, that the index are not up to date.
Unfortunately I am not a specialist of php.