Domino 9 und frühere Versionen > Entwicklung

ODBC mySQL- Notes Grösse Rückgabe

<< < (2/3) > >>

m3:
Also "MEMO" ist IIRC kein offizieller MySQL Feldtyp.  Du meinst wahrscheinlich "TEXT", oder?

--- Zitat --- A BLOB is a binary large object that can hold a variable amount of data. The four BLOB types, TINYBLOB, BLOB, MEDIUMBLOB, and LONGBLOB, differ only in the maximum length of the values they can hold.
The four TEXT types, TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT, correspond to the four BLOB types and have the same maximum lengths and storage requirements.
BLOB columns are treated as binary strings (byte strings). TEXT columns are treated as non-binary strings (character strings).
...
 MySQL Connector/ODBC defines BLOB values as LONGVARBINARY and TEXT values as LONGVARCHAR.
--- Ende Zitat ---
http://dev.mysql.com/doc/mysql/en/blob.html

Wenn das Feld vom Typ "BLOB" ist, solltest Du den Typ auf "TEXT" aendern. Laut Google liefert ein select dann mehr als 255 Zeichen zurueck.

Kressner:
habe gerade mal ein bisschen rumexperimentiert, folgenden agenten benutzt:

sql := "UPDATE tpages SET content='"+@Abstract([Abbrev];7900;"";body)+"' WHERE exlink='"+@Text(@DocumentUniqueID)+"'";
@DbCommand("ODBC":"NoCache";"tumaini";"mysql";"mysql";  sql);
SELECT @All

- pro sql-statement können ca. 8000 Zeichen übertragen werden
- anders herum können wiederum 512 zeichen pro datensatz bzw. 32K gesamt
  pro statement übertragen werden.

wenn also mehr als 512 zeichen importiert werden soll, muss das resultset chunk-weise
mit substring-statements geholt und wieder zusammengebaut werden ...

Marinero Atlántico:

--- Zitat von: Kressner am 01.03.05 - 17:35:09 ---
--- Code: ---sql := "UPDATE tpages SET content='"+@Abstract([Abbrev];7900;"";body)+"' WHERE exlink='"+@Text(@DocumentUniqueID)+"'";

--- Ende Code ---

--- Ende Zitat ---
Danke für die sehr detaillierte Hilfe.
Ein bischen eine andere Frage (hoffe das wird nicht als Thread-Hijacking angesehen).
Ist das wirklich sicher.
Bin nicht wirklich ein SQL Guru, aber kann ein böser Mensch nicht vielleicht über bestimmte klevere Zeichen-Kombinationen Dinge in der Datenbank anrichten, die der Programmierer nicht will?

z.B. in das Textfeld:
"*"; UPDATE tpages SET content="**"
Der SQL Befehl könnte dann heissen:

--- Code: ---UPDATE tpages SET content="*";
UPDATE tpages SET content="**" WHERE exlink="432234def8347598732";

--- Ende Code ---
Der content-Wert wäre dann * in fast allen Tupeln ausser in einer und dort "**".
Wie gesagt. Kann mich irren, ob das so wirklich funktioniert, habe ich nicht getestet.
Jedenfalls gibt es Situationen, wo RDBMS SQL Statements aus einem Programm so manipuliert werden können.
In JDBC gibt es sowas wie Prepared Statements, wo man sich davor schützen kann. Gibt es das in ODBC nicht?

Gruß Axel

MadMetzger:
So ist es, das was du meinst Axel, nennt sich SQL-Injection. Das Ganze läßt sich halt nur verhindern, wenn man solche Abfragen, bzw. die Argumente, die ermittelt werden, vorher genau überprüft.

Marinero Atlántico:

--- Zitat von: Alexis Pyromanis am 01.03.05 - 18:19:52 ---Das Ganze läßt sich halt nur verhindern, wenn man solche Abfragen, bzw. die Argumente, die ermittelt werden, vorher genau überprüft.

--- Ende Zitat ---

In JDBC gibt es sowas wie PreparedStatements. Quasi präkompiliertes SQL.

http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html
Da gibt es dieses low-level Probleme nicht.
z.B:

--- Code: ---1 PreparedStatement updateSales = con.prepareStatement(
"UPDATE COFFEES SET SALES = ? WHERE COF_NAME LIKE ? ");
2 updateSales.setInt(1, 75);
3 updateSales.setString(2, "Colombian");
4 updateSales.executeUpdate():

--- Ende Code ---
Selbst wenn man jetzt statt Zeile 3 sagen würde:

--- Code: ---updateSales.setString(2, "\"Colombian\"; UPDATE COFFEES SET SALES =\"Colombian\");

--- Ende Code ---
würde das in der Runtime nicht akzeptiert.
Datenbank APIs auf noch höheren Level wie Hibernate, Entity EJB, JDO, iBatis, uvam sind auch gegen solche Zugriffe vom Framework aus geschützt.
Existiert in ODBC wirklich nicht sowas wie Prepared Statements?
Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete