Du bist nicht angemeldet. Der Zugriff auf einige Boards wurde daher deaktiviert.

#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

piratos schrieb:

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)