ODBC mySQL- Notes Grösse Rückgabe

[Flair]

Hallo Leute,

Folgendes Problem: ich greife über ODBC von Notes auf eine mySQL Datenbank zu. In der Datenbank sind sog. MEMO Felder in denen eine Menge Text steht. Beim Auslesen dieser Felder bekomme ich nur einen Teil des vorhandenen Textes als einen String zurück!
Ich benutze folgendes Script (Auszug)
...
...
dim lcResult as New ODBCResultSet
...
...
lcResult.CommitOnDisconnect= True
Set lcResult.Query = lcQry
lcResult.CacheLimit=DB_ALL
lcResult.Asynchronous= True

Call lcResult.Execute()

lcDoc.Feld = lcResult.GetValue(1)
...
...
...

Wie gesagt: ich bekomme zwar Text, aber leider nicht den kompletten.
Wäre toll wenn mir hier einer helfen kann.
cu
Flair

[Glombi]

Aus der KBASE:

The NotesSQL ODBC driver has settings that limit the maximum number of characters for text and rich text fields.  The default is 254 characters for the text fields and 512 characters for the rich text fields.  Even though the maximum number of characters for the rich text field is 512, MS Access uses the limit set for text fields. 

To determine the "Max length ..." settings for your DSN, open the ODBC Data Source Administrator from the Control Panel.  Find your data source on the User DSN or System DSN tabs and click the Configure button.  The following window displays.  This window displays the default settings for the NotesSQL driver.


The following are excerpts from the NotesSQL.NSF Help file.

Max Length of Text Fields
   This parameter specifies the maximum number of bytes NotesSQL allows in a string. This limits the number of characters returned from a Notes text field and the length of a string to be inserted into a Notes text field.

   The maximum value allowed is 15,360. The minimum value allowed is 2.

   The default value is 254.  If the database will be used exclusively or primarily with Lotus 1-2-3(R), we recommend a value of 511.  This is the maximum length of a string in a cell in Lotus 1-2-3.

Max Length of Rich Text Fields
   This parameter is the same as Max Length of Text Fields, but for rich text fields.

   The maximum value allowed is 15,360. The minimum value allowed is 2.

   The default value is 512.  If the database will be used exclusively or primarily with Lotus 1-2-3, we recommend a value of 511.  This is the maximum length of a string in a cell in Lotus 1-2-3.

Note:  Notes databases have long text fields called rich text fields. The Body field of a Notes document is often a rich text field. If you want to retrieve all the data in such a field, be sure that the maximum string length you specify is large enough.


Andreas

[Glombi]

und

Only the First 254 Characters from a Notes Field in an MS Access Table Are Displayed

Problem:

You are using MS Access and attempt to bring a Notes text field into your Access table.  You find, however, that the table entry brings in only the first 254 characters of the Notes text field.

Steps to reproduce;

(Note:  You must be attempting to link a table to Notes through an ODBC source in Notes.)

1.   In MS Access, open your table (can be blank or existing).
2.   Click the new button and select Link Tables from the options.
3.   In the next screen, select file types of ODBC databases; you see the ODBC sources that you have created through the Windows Control Panel ODBC data sources (32 bit).  (Note that the source was selected from the machine data source tab.)

Solution:

This is not a Notes issue, but rather a matter of setting the ODBC source in the Windows Control Panel as follows:

1.   Select the source you are referencing in Access and click the Configure button.
2.   You should see a option field "Max Length of Text Fields" in the lower half of the dialog box.
3.   Increase this setting from 254 (the default) to a higher number.

Note that there is also an option for Max Length of Rich Text Fields.  For further information on configuring this and other setup options, refer to the document titled "Rich Text is Limited to 254 Characters when Using MS Access with the NotesSQL Driver" (#: 170947 ).

[Flair]

Hallo .
Danke für die schnelle Antwort, aber ....
Leider kann ich damit nix anfangen! In meiner mySQL ODBC Schnittstelle kann ich diesen Wert 'max Length' nirgends eintragen!
Es handelt sich um den offiziellen ODBC Treiber von mySQL ...
Bin total ratlos   

[Marinero Atlántico]

versuch dir das hier mal anzuschauen:
http://dev.mysql.com/doc/mysql/en/dsn-on-windows.html
Da scheint es z.B. eine Option "Allow BIG results" zu geben. So aus dem Bauch heraus würde ich jetzt sagen, aber ich weiss es natürlich auch nicht.
Ansonsten helfen vermutlich mySQL spezifische Foren/newsgroups besser.

[m3]

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

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.

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]

Code

sql := "UPDATE tpages SET content='"+@Abstract([Abbrev];7900;"";body)+"' WHERE exlink='"+@Text(@DocumentUniqueID)+"'";

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";

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]

Das Ganze läßt sich halt nur verhindern, wenn man solche Abfragen, bzw. die Argumente, die ermittelt werden, vorher genau überprüft.

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():

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

Code

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

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

[MadMetzger]

Die Frage wiederum kann ich nicht beantworten... aber deine Ausführungen sind schon recht interessant, vor allem da ich mich ab Sommer im Studium mit Java beschäftigen werde.