Du bist nicht angemeldet. Der Zugriff auf einige Boards wurde daher deaktiviert.
Seiten: 1
#1 03. März 2011 16:57
- piratos
- Gast
[GELÖST] Die ersten Probleme Adodb Lite und Mysql
Wie CG zu Recht berichtete verwendet die Lite Version das Format CREATE TABLE ... TYPE=TABLETYPE wobei TYPE=... schon lange deprecated ist und unter Mysql 5.5 zu Fehlern führt.
Korrekt wäre ENGINE=TABLETYPE .
Da Lite definitiv tot ist wird er in der nächsten Version eine gepatchte Lite Version beilegen um das zu umgehen und um insbesondere die Lauffähigkeit von externen Modulen zu gewährleisten - der einzig richtige Weg.
In dem Zusammenhang sollte man - wenn eigene Module oder Tags mit Mysql geschrieben werden Tabelle- und Feldnamen ohne Ausnahme escapen - also
`name` , da unter 5.5 wie auch unter 6 die Anzahl für Mysql reservierter Wörter ordentlich zugenommen hat.
Verwendet man z.B. einen Tabellennamen intervall ohne den zu escapen, ist das eine SQL Fehler.
CG hat übrigens in dem Zusammenhang geschrieben
(for those of you that wonder why we still use an abstraction library even if MySQL is the de-facto standard database for CMSMS... this is it),
um so mehr wundert es mich, das in der V 2 wieder ein solches Zeug kommen wird.
#2 11. März 2011 10:04
- Andynium
- Moderator
- Ort: Dohna / SN / Deutschland
- Registriert: 13. September 2010
- Beiträge: 7.018
- Webseite
Re: [GELÖST] Die ersten Probleme Adodb Lite und Mysql
um so mehr wundert es mich, das in der V 2 wieder ein solches Zeug kommen wird.
Ich denke mal, dass liegt an den unterschiedlichen Standpunkten von Ted und Robert.
Ted plant die V2, während Robert sich bemüht, die V1 am Laufen zu halten - wobei sich dann die Frage stellt, warum man nicht gleich wieder die ADOdb full mitliefert, anstatt sich den Stress zu machen, in Fremd-Libs rumzuändern ...
Offline
#3 11. März 2011 11:17
- piratos
- Gast
Re: [GELÖST] Die ersten Probleme Adodb Lite und Mysql
Ich denke Ted möchte lieber etwas fertiges verwenden, als sich die Mühe zu machen eine eigene Klasse zu schreiben.
Und - es erzeugt ja den Anschein einer gewissen Größe und Bedeutung bei der Verwendung eines Layersystems - auch wenn man in der Praxis kaum Anwender anderer DB's ausser Mysql haben wird und man sich mit Sicherheit die Mühe spart individuelle SQL zu schreiben um die besonderen Merkmale eines DB-Systems zu nutzen - die Folge - Einfachstsql.
Die schnellste Methode ist die direkte Verwendung von PDO - da gibt es reichlich Treiber von Haus aus:
MS SQL Server (PDO) — Microsoft SQL Server and Sybase Functions (PDO_DBLIB)
Firebird/Interbase (PDO) — Firebird/Interbase Functions (PDO_FIREBIRD)
IBM (PDO) — IBM Functions (PDO_IBM)
Informix (PDO) — Informix Functions (PDO_INFORMIX)
MySQL (PDO) — MySQL Functions (PDO_MYSQL)
Oracle (PDO) — Oracle Functions (PDO_OCI)
ODBC and DB2 (PDO) — ODBC and DB2 Functions (PDO_ODBC)
PostgreSQL (PDO) — PostgreSQL Functions (PDO_PGSQL)
SQLite (PDO) — SQLite Functions (PDO_SQLITE)
Aber auch hier gilt - individuelle SQL für jedes System.
Daran scheitert es in erster Linie bei den Hauptentwicklern, denn die müssen die Core ja auch testen können und es scheitert garantiert bei den externen Moduleentwicklern, die haben da noch weniger Chancen als die DEV's sie vielleicht hätten.
Meine Empfehlung - konzentriert euch auf DB's die alle zur Verfügung haben das wäre Mysql .
Nutzt eine eigene Klasse auf Basis PDO, weil ich annehmen darf, das bei vielen Moduleentwicklern die Programmierkenntnisse im Detail nicht ausreichen um PDO direkt einzusetzen, ausserdem spart man sich so einige Programmzeilen.
Beitrag geändert von piratos (11. März 2011 11:23)
Seiten: 1