RootForum Community

Posted: **2006-05-19 10:32**

Hallo,
Hoffentlich habe ich hier das richtige Subforum erwischt. Ansonsten Sorry und bitte/gerne verschieben.

Als Computerlaie sollte man die Fingern von Datenbanken etc. lassen, hätte ich mal auf Mutti gehört :roll: Immerhin habe ich es mit der Zeit geschafft, Datenbanken zumindest ansatzweise zu nutzen. Habe unter anderem zwei nichtkommerzielle Projekte, für die ich nun einen Server einrichten lies, bei 1und1. Dort hatte ich bisher einen Webhostingvertrag.

Wer schauen mag, auf welches Projekt sich die Problematik bezieht, der kann auf http://www.mexiko-lexikon.de vorbeisurfen. Ein Wiki, auf Mediawiki basierend. Habe auch ein Board, http://www.mexico-mexiko.com , das ich aufgrund der Datenbankgröße auslagern musste und in einer paar Wochen ebenfalls auf den Server legen möchte und das ganze, soll helfen noch ein paar Rollstühle über meinen Verein Mexiko Hilfswerk e.V. zu finanzieren.

Also, wer mir hilft tut dies für eine gute Sache

(Ist witzig gemeint, stimmt aber auch)

Also, es geht jetzt speziell um das Wiki unter http://www.mexiko-lexikon.de. Ich komme nicht weiter und versuche das Problem knapp und verständlich zu formulieren.

- Umstellung Webhosting - Server beantragt und erfolgt
- Dateien, Skripte... liegen auf dem Server und greifen für zwei Wochen noch auf die alten() Datenbanke(n) zu
- Funktioniert einwandfrei. Muss nun aber die DAtenbanken umziehen.
- Leider: Webhosting verwendet mysql5 - Server mysql4
- habe letzte sicherung vom Support (einer hats vor einer Woche auf Wunsch gemacht, alle anderen vom neuen Serversupport weigern sich aktuell) sichern und in mysql4 konvertieren lassen.
- habe diese Datenbank auf localhost eingespielt, was klappte.
- scripte in Wediamiki angepasst.
- konnte leider im Wiki nur lesen und nicht schreiben :(
"old_id" NULL Problem

- Habe dann aktuellste Mediawikiversion eingespielt, Update gestartet, Installationsrotine konnte nich beendet werden.
- Konnte im Wiki problemlos surfen/lesen, aber nicht schreiben

- habe sicherheitshalber getestet, ob der Fehler bei mir lag. Wediamiki in eine andere DAtenbank komplett neu installiert. Funktioniert ganz problemlos. Keine Fehlermeldung in der Installationsroutine, wie früher...

- Problem liegt also meiner Meinung nach in der konvertierten und nun einzuspielenden DAtenbank. Der Support von 1und1 ist teils sehr höflich, teils am Rande der Unverschämtheit. Auf jeden Fall stehe ich nun mit dem Problem alleine da :evil:

Wie lautet der Befehl, damit ich es selbst nochmal versuchen kann, mysql5 beim dumpen in mysql4 zu konvertieren. Vielleicht hat der Mitarbeiter einen Fehler gemacht. (Der Support kann/mag mir den Befehl nicht nennen, fand ihn auch nicht mehr, obwohl ich vor einer Woche diesen noch googeln konnte. Sorry)

Laut 1und1 soll ich die bestehende konvertierte Sicherung, mit der es nach dem Einspielen Probleme gibt, editieren:

Sehr geehrter Herr Koch,

legen Sie von der betreffenden DB eine lokale Sicherung an, einen sog.
MySQL Dump. Das können Sie über die MySQL-Verwaltung des ControlCenters
mit der Funktion "Exportieren" machen.

Die dabei entstehende SQL-Datei lässt sich mit einem normalen Texteditor
bearbeiten.

Ändern Sie die Spalte `text` so, dass "old_id" NULL werden kann.

Dann sollte der import funktionieren.

Mit freundlichen Grüßen

Matthias O.
Technischer Support
1&1 Internet AG

Und wie mach ich das???? Laut M. O. mit Hilfe von RootForum, vielleicht würde sich dort jemand finden, der mir helfen kann. Ich finde das nicht wirklich gut, das so auf die Allgemeinheit abzuschieben. Aber... ich bin auf Hilfe angewiesen.

Hat jemand eine Idee, soll ich die Fehlermeldungen nochmals expizit posten???

Würde mich freuen, Hilfe erfahren zu können.

Gruß
Oliver

Posted: **2006-05-19 10:40**

Lies http://dev.mysql.com/doc/refman/4.1/en/mysqldump.html und schau dir vor allem den Parameter --compatible an.

Posted: **2006-05-19 10:53**

Habe bei google nach convert... gesucht. Merci, habe gesichert, mit --compatible=mysql40 - Ging ohne Fehler, auch das einspielen in die Datenbank auf dem Server funktionierte.

Habe die Skripte angepasst, das Wiki lässt sich lesen und beim Editieren bekomme ich leider folgende Fehlermeldung:

Es gab einen Syntaxfehler in der Datenbankabfrage. Die letzte Datenbankabfrage lautete:
(SQL query hidden)
aus der Funktion "Revision::insertOn". MySQL meldete den Fehler "1048: Column 'old_id' cannot be null (localhost)".

Werde gleich die Installationsroutine von Mediawiki starten und die Fehlermeldung hier posten.

Posted: **2006-05-19 11:02**

Die Meldungen des Wiki beim Start der Installationsroutine:

* PHP 4.4.2 installed
*
Warning: PHP's register_globals option is enabled. Disable it if you can.
MediaWiki will work, but your server is more exposed to PHP-based security vulnerabilities.
* PHP server API is cgi; using ugly URLs (index.php?title=Page_Title)
* Have XML / Latin1-UTF-8 conversion support.
* PHP's memory_limit is 40M. If this is too low, installation may fail!
* Have zlib support; enabling output compression.
* Neither Turck MMCache nor eAccelerator are installed, can't use object caching functions
* GNU diff3 not found.
* Found GD graphics library built-in, image thumbnailing will be enabled if you enable uploads.
* Installation directory: /homepages/13/d133932717/htdocs/mexiko-lexikon2006/mexiko
* Script URI path: /mexiko
* Environment checked. You can install MediaWiki.

Nach Eingabe der Daten, wie es auf beim Webhosting klappte und auch bei dem heute ganz neu installierten Wiki auf dem Server, kommt folgende Meldung:

# PHP 4.4.2 installed
#
Warning: PHP's register_globals option is enabled. Disable it if you can.
MediaWiki will work, but your server is more exposed to PHP-based security vulnerabilities.
# PHP server API is cgi; using ugly URLs (index.php?title=Page_Title)
# Have XML / Latin1-UTF-8 conversion support.
# PHP's memory_limit is 40M. If this is too low, installation may fail!
# Have zlib support; enabling output compression.
# Neither Turck MMCache nor eAccelerator are installed, can't use object caching functions
# GNU diff3 not found.
# Found GD graphics library built-in, image thumbnailing will be enabled if you enable uploads.
# Installation directory: /homepages/13/d133932717/htdocs/mexiko-lexikon2006/mexiko
# Script URI path: /mexiko
# Environment checked. You can install MediaWiki.

Generating configuration file...
# Database type: mysql
# PHP is linked with old MySQL client libraries. If you are using a MySQL 4.1 server and have problems connecting to the database, see http://dev.mysql.com/doc/mysql/en/old-client.html for help.
# Attempting to connect to database server as dbo163882916...success.
# Connected to 4.0.25-standard
# Database db163882916 exists
# There are already MediaWiki tables in this database. Checking if updates are needed...# PHP 4.4.2 installed
#
Warning: PHP's register_globals option is enabled. Disable it if you can.
MediaWiki will work, but your server is more exposed to PHP-based security vulnerabilities.
# PHP server API is cgi; using ugly URLs (index.php?title=Page_Title)
# Have XML / Latin1-UTF-8 conversion support.
# PHP's memory_limit is 40M. If this is too low, installation may fail!
# Have zlib support; enabling output compression.
# Neither Turck MMCache nor eAccelerator are installed, can't use object caching functions
# GNU diff3 not found.
# Found GD graphics library built-in, image thumbnailing will be enabled if you enable uploads.
# Installation directory: /homepages/13/d133932717/htdocs/mexiko-lexikon2006/mexiko
# Script URI path: /mexiko
# Environment checked. You can install MediaWiki.

Generating configuration file...
# Database type: mysql
# PHP is linked with old MySQL client libraries. If you are using a MySQL 4.1 server and have problems connecting to the database, see http://dev.mysql.com/doc/mysql/en/old-client.html for help.
# Attempting to connect to database server as dbo163882916...success.
# Connected to 4.0.25-standard
# Database db163882916 exists
# There are already MediaWiki tables in this database. Checking if updates are needed...

Code: Select all

...hitcounter table already exists.
...querycache table already exists.
...objectcache table already exists.
...categorylinks table already exists.
...logging table already exists.
...validate table already exists.
...user_newtalk table already exists.
...transcache table already exists.
...trackbacks table already exists.
...externallinks table already exists.
...job table already exists.
...have ipb_id field in ipblocks table.
...have ipb_expiry field in ipblocks table.
...have rc_type field in recentchanges table.
...have rc_ip field in recentchanges table.
...have rc_id field in recentchanges table.
...have rc_patrolled field in recentchanges table.
...have user_real_name field in user table.
...have user_token field in user table.
...have user_email_token field in user table.
...have user_registration field in user table.
...have log_params field in logging table.
...have ar_rev_id field in archive table.
...have ar_text_id field in archive table.
...have page_len field in page table.
...have rev_deleted field in revision table.
...have img_width field in image table.
...have img_metadata field in image table.
...have img_media_type field in image table.
...have val_ip field in validate table.
...have ss_total_pages field in site_stats table.
...have iw_trans field in interwiki table.
...have ipb_range_start field in ipblocks table.
...have ss_images field in site_stats table.
...already have interwiki table
...indexes seem up to 20031107 standards
Already have pagelinks; skipping old links table updates.
...image primary key already set.
The watchlist table is already set up for email notification.
...watchlist talk page rows already present
...user table does not contain old email authentication field.
Logging table has correct title encoding.
...page table already exists.
revision timestamp indexes already up to 2005-03-13
...rev_text_id already in place.
...page_namespace is already a full int (int(11)).
...ar_namespace is already a full int (int(11)).
...rc_namespace is already a full int (int(11)).
...wl_namespace is already a full int (int(11)).
...qc_namespace is already a full int (int(11)).
...log_namespace is already a full int (int(11)).
...already have pagelinks table.
...templatelinks table already exists
No img_type field in image table; Good.
Already have unique user_name index.
...user_groups table already exists.
...user_groups is in current format.
...wl_notificationtimestamp is already nullable.
...timestamp key on logging already exists.
Setting page_random to a random value on rows where it equals 0...changed 0 rows
Initialising "MediaWiki" namespace...
A database error has occurred
Query: INSERT  INTO `text` (old_id,old_text,old_flags) VALUES (NULL,'[[$1]] wurde über eine Weiterleitung nach [[$2]] verschoben','utf-8')
Function: Revision::insertOn
Error: 1048 Column 'old_id' cannot be null (localhost)

Backtrace:
GlobalFunctions.php line 602 calls wfbacktrace()
Database.php line 473 calls wfdebugdiebacktrace()
Database.php line 419 calls databasemysql::reportqueryerror()
Database.php line 1023 calls databasemysql::query()
Revision.php line 624 calls databasemysql::insert()
Article.php line 2452 calls revision::inserton()
InitialiseMessages.inc line 199 calls article::quickedit()
InitialiseMessages.inc line 72 calls initialisemessagesreal()
updaters.inc line 822 calls initialisemessages()
index.php line 659 calls do_all_updates()

Die Installation ist also nicht abgeschlossen. Wohl wegen:

Code: Select all

Initialising "MediaWiki" namespace...
A database error has occurred
Query: INSERT  INTO `text` (old_id,old_text,old_flags) VALUES (NULL,'[[$1]] wurde über eine Weiterleitung nach [[$2]] verschoben','utf-8')
Function: Revision::insertOn
Error: 1048 Column 'old_id' cannot be null (localhost)

Und nu :?

Gruß Oliver

Zum Glück greift mein Adrenalinüberschuss aus der durchgemachten Nacht, sonst würde ich mich noch viel mehr ärgern...

Ergänzung zur Infor, bei der Installation habe ich mich wie immer für die erste der Optionen entschieden:

Database charset
Select one:
* Backwards-compatible UTF-8
* Experimental MySQL 4.1/5.0 UTF-8
EXPERIMENTAL: You can enable explicit Unicode charset support for MySQL 4.1 and 5.0 servers. This is not well tested and may cause things to break. If upgrading an older installation, leave in backwards-compatible mode.

Posted: **2006-05-19 23:51**

Technischer Support 1&1 Internet AG wrote:... von der betreffenden DB eine lokale Sicherung an ... SQL-Datei lässt sich mit einem normalen Texteditor
bearbeiten.

Ändern Sie die Spalte `text` so, dass "old_id" NULL werden kann.

Mag dies versuchen. Wie muss ich nun folgenden Text editieren?

Code: Select all
```
`old_id` int(8) unsigned NOT NULL
```

Oliver

Posted: **2006-05-20 02:45**

Es geht mir nicht darum, immer wieder auf das Thema hier hinzuweisen... SORRY :oops:
Ich arbeite nur selbst im Hintergrund auch an dem Problem. Allerdings ohne Lösung. Alles klappt, wenn ich es neu erstelle etc... aber das umkonvertieren und einspielen klappt nicht. Per Shell gibt es wohl keine Fehlermeldung, aber die Problematik bleibt.

Habe als letzten Versuch die Tabellen (also Installationsroutine) neue erstellen lassen. (Lese-Schreibtest funzte) Dann den Dump dort überspielt... Folge: Gleicher Fehler:

Es gab einen Syntaxfehler in der Datenbankabfrage. Die letzte Datenbankabfrage lautete:
(SQL query hidden)
aus der Funktion "Revision::insertOn". MySQL meldete den Fehler "1048: Column 'old_id' cannot be null (localhost)".

Habe für den Dump folgenden Befehl zusammengestellt.
mysqldump -h********.de -u******* -p***** db**** --default-character-set=latin1 --compatible=mysql40 > dblex_xy.sql

(Siehe auch hier)

So, ich geb vorläufig auf

Oliver ](*,)

Posted: **2006-05-20 14:48**

Hallo Oliver,

oliverkoch wrote: Habe für den Dump folgenden Befehl zusammengestellt.
mysqldump -h********.de -u******* -p***** db**** --default-character-set=latin1 --compatible=mysql40 > dblex_xy.sql

Probiere mal den Dump noch mit den Aktionen --add-drop-table und --complete-insert zu erstellen, also

mysqldump -h*** -u*** -p**** db*** --default-character-set=latin1 --compatible=mysql40 --add-drop-table --complete-insert > dblex_xy.sql

Dabei wird die Originalstruktur der Datenbank erhalten, und es solte eigentlich funktionieren!

Hoffe es klappt!
Gruß
Tobi

Posted: **2006-05-20 15:51**

Vielen Dank Tobi,

habe vor dem Einspielen der Datenbank per shell die Funktionalität der Datenbank getestet, da ich diese über die Installationsroutine schon erstellt habe. Sie funktioniert.

Nach dem dumpen und einspielen der Datenbank (ohne Shellfehlermeldung), das gewohnte Problem. Lesen klappt, beim Versuch zu schreiben kommt folgender Fehler:

Es gab einen Syntaxfehler in der Datenbankabfrage. Die letzte Datenbankabfrage lautete:
(SQL query hidden)
aus der Funktion "Revision::insertOn". MySQL meldete den Fehler "1048: Column 'old_id' cannot be null (localhost)".

Habe versucht, die Installationsroutine darüber zu installieren. Das führt dann zu der schon oben aufgeführten Meldung beim Ausführen der Installationsroutine.

:(

Oliver

Posted: **2006-05-20 16:09**

Okay,

dann probier dochmal folgendes:

Ändere, wie dieser 1&1 Support geschrieben hat, die Zeile

`old_id` int(8) unsigned NOT NULL um in

`old_id` int(8) unsigned

Ich gehe aber schwer davon aus, dass Du dann das Problem nicht mehr haben wirst, dafür aber ein anderes!

Gruß und viel Glück
Tobi

Posted: **2006-05-20 16:40**

http://www.google.com/search?hl=en&q=me ... gle+Search

Posted: **2006-05-20 18:39**

Habe folgenden Code

Code: Select all

(
  `old_id` int(8) unsigned NOT NULL,
  `old_namespace` tinyint(2) unsigned NOT NULL default '0',
  `old_title` varchar(255) binary NOT NULL default '',
  `old_text` mediumtext NOT NULL,
  `old_comment` tinyblob NOT NULL,
  `old_user` int(5) unsigned NOT NULL default '0',
  `old_user_text` varchar(255) binary NOT NULL default '',
  `old_timestamp` varchar(14) binary NOT NULL default '',
  `old_minor_edit` tinyint(1) NOT NULL default '0',
  `old_flags` tinyblob NOT NULL,
  `inverse_timestamp` varchar(14) binary NOT NULL default '',
  PRIMARY KEY  (`old_id`),
  KEY `old_timestamp` (`old_timestamp`),
  KEY `name_title_timestamp` (`old_namespace`,`old_title`,`inverse_timestamp`),
  KEY `user_timestamp` (`old_user`,`inverse_timestamp`),
  KEY `usertext_timestamp` (`old_user_text`,`inverse_timestamp`)
) TYPE=MyISAM;

--
-- Dumping data for table `text`
--

in der ersten Zeile editiert und "NOT NULL" gelöscht:

Code: Select all

(
  `old_id` int(8) unsigned,
  `old_namespace` tinyint(2) unsigned NOT NULL default '0',
  `old_title` varchar(255) binary NOT NULL default '',
  `old_text` mediumtext NOT NULL,
  `old_comment` tinyblob NOT NULL,
  `old_user` int(5) unsigned NOT NULL default '0',
  `old_user_text` varchar(255) binary NOT NULL default '',
  `old_timestamp` varchar(14) binary NOT NULL default '',
  `old_minor_edit` tinyint(1) NOT NULL default '0',
  `old_flags` tinyblob NOT NULL,
  `inverse_timestamp` varchar(14) binary NOT NULL default '',
  PRIMARY KEY  (`old_id`),
  KEY `old_timestamp` (`old_timestamp`),
  KEY `name_title_timestamp` (`old_namespace`,`old_title`,`inverse_timestamp`),
  KEY `user_timestamp` (`old_user`,`inverse_timestamp`),
  KEY `usertext_timestamp` (`old_user_text`,`inverse_timestamp`)
) TYPE=MyISAM;

--
-- Dumping data for table `text`
--

Habe die Datenbank dann hochgeladen und eingespielt. Gleiche Fehlermeldung.

Es gab einen Syntaxfehler in der Datenbankabfrage. Die letzte Datenbankabfrage lautete:
(SQL query hidden)
aus der Funktion "Revision::insertOn". MySQL meldete den Fehler "1048: Column 'old_id' cannot be null (localhost)".

Dann sicherheitshalber alle vorher bestehenden Tabellen gelöscht und den Dump in die leere Datenbank gespielt. Wie gehabt, lesen möglich, schreiben nicht. Gleiche Fehlermeldung.

Leider!!!

Noch ein Tipp????

Oliver

Posted: **2006-05-20 19:02**

oliverkoch wrote: Noch ein Tipp????

Ich bin jetzt erstmal mit dem Latein am Ende. Ich habe mir mal die Suchergebnisse bei google angeschaut, kann damit aber auch nichts anfangen! Evtl. kann ich am Montag jemanden bei der Arbeit fragen. Kann aber nicht versprechen, dass es jemand weiß.

Viel Glück weiterhin
Tobi

Posted: **2006-05-21 03:39**

Hi Tobi und andere...

musste in der Datenbank manuell "auto_increment" einstellen für "old_id", "user_id", "job".......

Empfehlung für User, die vielleicht mal das gleiche Problem haben: Neuinstallation in neue Datenbank, jeweilige Version in der Struktur vergleichen... und Glück haben. (Zum Glück hab ich zwei Monitore!) Die Tabellen sind schon recht unterschiedlich. Hoffe, dass es klappt!!!!!!!!

Gruß
Oliver

(Habe manuell alle Artikel, Bildbeschreibungen etc. in ein neues Wiki importiert. Kann dies nur für den absoluten Notfall empfehlen. Zum einen ist es eine elendige und langwierige Arbeit, zum anderen sichert man so nur die Infos. Statistik, Artikelzahl, Funktionen, User etc... werden nicht übernommen. Hätte mir diese Arbeit sparen können, wenn es jetzt so klappt. Auf die Idee bin ich allerdings erst vor einer halben Stunde gekommen.)
8-[

RootForum Community

Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..

Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..

Re: Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..

Re: Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..

Re: Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..

Re: Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..

Re: Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..

Re: Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..

mysql5 -> mysql40 - Mediawiki

Re: Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..

Re: Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..

Re: Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..

Re: Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..

Re: Probleme mit 1und1, mysql5>mysql4 / `text` verändern, so dass "old_id" NULL..