MySQL kompatibilität

[dragon001]

Hab mein CMS inzwischen relativ fertig.
Wollte es jetzt bei einem Kunden testen.
Bei installieren gabs eigentlich keine MAcken.
Als ich dann die Module Installieren wollte (über ein eigenes Modul Isntallations System) ist mir aufgefallen das gar nix geht.
Hab mich auf die Suche gemacht und gesehen, das gar nix in die Datenbank geschrieben wurde.
Weder Sprachdateien, noch die Datenbank Einträge.
Hab per Echo die Querys ausgeben lassen.
über PHPmyAdmin die Querys auf dem System getestet.
Hat sofort fehler gegeben.
Nachgeschaut welche MySQL Version lief und hab gesehen, das die nur 3.2x einsetzen.
Ein problem für mich den ich verwende 4.1 hauptsächlich.

Gibt es ne Möglichkeit Querys im PHP aufruf zu konvertieren oder besser zu parsen, das Sie z.b.: 3.x kompatibel wären?

 

[society]

Lass den Kunden doch Updaten Ist einfacher. Oder du musst lernen MySQL 3 kompatiblel zu Programmieren

 

[Huschi]

Gibt es ne Möglichkeit Querys im PHP aufruf zu konvertieren oder besser zu parsen, das Sie z.b.: 3.x kompatibel wären?

<neugier>
Kannst Du mal ein Beispiel von Querys geben, die in MySQL 3.x zu Fehlern führen?
</neugier>

huschi.

 

[dragon001]

An sich laufen Sie ja, sind nur die Sprachunterschiede:

MySQL 3 TYPE=MyISAM;
MySQL 4 Engine=MyISAM;

und noch andere.
Ich dachte, vielleicht kennt jemand ne Möglichkeit das ganze irgendwie zu umgehen ohne zwei getrennte System laufen zu lassen (eins MySQL3, das andere MySQL4).

Das einzige was trouble macht sind inserts und create (die anderen laufen soweit ich weiß).

Bei SQL Query Update erhalte ich beim exportieren strings wie diese: `irgendwas`='irgendetwas'
sind die ` eigentlich auch für MySQL 3 gültig?

 

[Huschi]

MySQL 3 TYPE=MyISAM;
MySQL 4 Engine=MyISAM;

Sorry, aber das ist ja jetzt kein SQL-Statement.
Ich meinte echte Beispiel, an denen man sehen kann, wo echte Differenzen sind.

Das einzige was trouble macht sind inserts und create (die anderen laufen soweit ich weiß).

Das hab ich mir schon gedacht, aber bitte konkrete Beispiele. Evtl. kann man Dir dann einen kleinen Tip geben, was daran zu ändern ist.

sind die ` eigentlich auch für MySQL 3 gültig?

Ja.

huschi.

 

[dragon001]

Beispiel:


CREATE TABLE `wpCMS_banner` (
`bid` int(11) NOT NULL auto_increment,
`cid` int(11) NOT NULL default '0',
`imptotal` int(11) NOT NULL default '0',
`impmade` int(11) NOT NULL default '0',
`clicks` int(11) NOT NULL default '0',
`imageurl` varchar(100) NOT NULL default '',
`clickurl` varchar(200) NOT NULL default '',
`alttext` varchar(255) NOT NULL default '',
`date` datetime default NULL,
`dateend` datetime default NULL,
`type` tinyint(1) NOT NULL default '0',
`active` tinyint(1) NOT NULL default '1',
PRIMARY KEY (`bid`),
KEY `bid` (`bid`),
KEY `cid` (`cid`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;



Mir ist klar, ersten Default Charset=latin1 ist MySQL 4.1, an was sich die Scripts aufhängen ist mal hauptsächlich das Engine=MyISAM.

Das ganze zu parsen ist eigentlich kein Problem.
Inserts funktionieren eigentlich immer (mit einer Ausnahme:

Hab die Tabellen per Hand angelegt.
Waren ca 2000 Inserts.
Beim Eingeben hat PHPmyAdmin immer wieder rumgenörgelt das einträge bereits existieren.
(waren welche aus der laufenden Query).
Und lauter so spielchen.
Wegen diesen kleineren Problemen hab ich den Kunden auf meinen Server übernommen und die MySQL 3 Probleme aus dem Weg schaffen.
Werd meine Software also absofort mit min. MySQL4.0 labeln.
Kommt aus folgendem Grund: eines der Module verwendet joins.

MFG
draco

 

[Huschi]

an was sich die Scripts aufhängen ist mal hauptsächlich das Engine=MyISAM.

Der Typ/Engine MyISAM ist aber ebenfalls die Default-Einstellung. Kann also auch weggelassen werden.

Kommt aus folgendem Grund: eines der Module verwendet joins.

Falls Du 'inner join' meinst, die konnte MySQL3 tatsächlich in der Form nicht. Sind aber leicht mit 'left join' emulierbar.

huschi.

 

[st@eff.en]

Ersmal die Unterschiede:

ab MySQL 4.1 treten die Änderungen ein.

Dabei hast Du Inkompatibilitäten bei
CREATE TABLE
und bei Benutzung von Charsets und Collations.

Mit MySQLDumper ist eine Konvertierungsroutine eingebaut, um von MySQL>4.1 Backups für MySQL<4.1 zu erzeugen.

Innerhalb von normalen Select-Queries musst Du nur auf Collations und Charset-Anweisungen verzichten, ansonsten wirst Du damit keine Probleme haben