Domino 9 und frühere Versionen > ND6: Entwicklung
dynamischer Export zu Access
flaite:
Hallo Ralf,
--- Zitat von: Ralf_M_Petter am 19.03.06 - 10:20:33 ---Ich denke mal du hast dir den Link nicht angeschaut und deshalb reden wir aneinander vorbei. In dem Link ist nämlich beschrieben, dass updateRow eben unter bestimmten Umständen nicht funktioniert. Damit bin ich auch schon auf die Nase gefallen. Und es wird unter diesem Link empfohlen, mit dem SQL Statement Insert zu arbeiten.
--- Ende Zitat ---
Stimmt. Antwort von Import-Bot. Mich hätte es sowieso gewundert, wenn das stabil funktionieren würde. Wie soll entschieden werden, ob ein insert oder ein update gemacht werden soll?
--- Zitat ---Wenn man jetzt 100 oder gar 1000 Inserts ausführen will sollte man auf jden Fall mit preparedStatements arbeiten, da sonst die performance furchtbar schlecht.
Das parsen und aufbereiten eines SQL Zugriffspfades ist eine extrem teure Operation und sollte auf jeden Fall nicht zu oft gemacht werden.
--- Ende Zitat ---
Schon richtig. D.h. mit den meisten Datenbanken gibt es noch spezielle batch-update oder batch-insert Operationen, die deutlich noch schneller sind. Aber das nur am Rande. Glaub das "commit" ist zumindest bei inserts noch kostspieliger als SQL Zugriffspfad.
Frage ist nur, wie man mit LS:DO preparedStatements für inserts implementieren soll?
ODBCQuery.SQL= "Insert Into blablabla (valuea, valueb, valuec)"
Geht das überhaupt dann noch über prepared Statements. Nach dieser (imho merkwürdigen api) über ODBCResultSet.setParameter(),
Ich bin nach wie vor der Meinung, dass man für diese Aufgabe auch mit Statements auskommt. Man muß nur den Zugriff auf den entsprechenden Code schützen. Ansonsten sind SQL injections natürlich gefährlich.
Da der entsprechende Algorythmus zwar überschaubar aber auch nicht mega-einfach sein wird, ist es vielleicht sogar schlau, erstmal mit normalen Statement anzufangen um dann auf preparedStatement zu wechseln.
Gruß Axel
Anfaenger:
Hallo Axel
Es hätte eigentlich so klappen sollen, aber wie gesagt, es hat leider nur mit manchen Views geklappt und meistens waren es dann die gleichen, so dass ich mich dann halt auf die suche gemacht hab. Und mit dem Insert hab ich es leider nur geschafft, das immer nur einmal pro Aufruf der AccessDB zu schreiben, was natürlich auch extrem blöd ist, weil es wirklich ewig dauert, um da n paar Zeilen reinzuschreiben.
Und ich weiss leider net, wie ich mit dem "INSERT INTO ..." mehrere Zeilen einfügen soll. Saß jetzt des ganze WE damit rum, das irgendwie hinzubekommen. Aber das einzigste was ich hinbekommen hab, ist, dass mein Access mir jetzt nur noch Zahlenfelder und keine Textfelder mehr anlegt. ;)
Schöne Grüße,
Axel
Ralf_M_Petter:
Muss morgen mal in der Firma ein wenig stöbern, ich glaube ich habe das mit Insert schon mal wo gemacht. Zwar nicht mit Access sondern mit DB/2 aber das sollte uns ja nicht stören. Schaue ob ich den Code posten kann. Wobei ich glaube, dass ich da auch nicht mit preparedStatement gearbeitet habe, da Domino auf der Iseries ein Problem mit preparedStatements hat. Arbeite deshalb schon seit längeren nur mit Java Agents in dem Bereich, die eine wesentliche bessere Unterstütztung von Datenbankzugriffen haben. zumindest im Iseries Umfeld.
Grüße
Ralf
flaite:
Hallo Axel,
--- Zitat von: Anfaenger am 19.03.06 - 16:58:44 ---Aber das einzigste was ich hinbekommen hab, ist, dass mein Access mir jetzt nur noch Zahlenfelder und keine Textfelder mehr anlegt. ;)
--- Ende Zitat ---
Das ist das Problem mit überehrgeizigen Projekten ;D
Man wird immer langsamer und gibt irgendwann auf. Ich weiss wovon ich rede.
Jedenfalls könntest du noch einmal versuchen:
--- Code: ---connection.AutoCommit = false ' (connection ist eine ODBCConnection)
--- Ende Code ---
und nach einer Reihe von insert Statements _
--- Code: ---connection.commitTransactions
--- Ende Code ---
Mach aber vorher die Relationalen (Tabellen) von Access völlig leer.
Aber wie gesagt, ist das automatische Erzeugen von RDBMS Schemen ein wirklich komplexes Thema. Da hängt eine Menge dran (Fremdschlüssel, Primärschlüssel sowie deren Generierungspolitik, Indexe und und und). Ganz automatisch sollte man RDBMS-Schemen sowieso nicht erzeugen, da eine Menge an Optimierungsmöglichkeiten existieren, die auch die besten Tools nicht hinbekommen.
Vergleich ich dies alles mit dem von mir favorisierten Hibernate, erzeugt mir hibernate zwar ein RDBMS Schema automatisch aus Objekten, jedoch hab ich da sehr weitreichende Editiermöglichkeiten, um eine Menge Sachen in einer Art Beschreibungssprache einzustellen (.hbm.xml-Dateien). Die Hibernate Entwickler haben da ein paar Jahre dran geschrieben. ;)
Gruß Axel
flaite:
--- Zitat von: Ralf_M_Petter am 19.03.06 - 17:58:04 ---Zwar nicht mit Access sondern mit DB/2 aber das sollte uns ja nicht stören.
--- Ende Zitat ---
Ich fürchte doch.
AFAIK waren multiple-inserts ein Bereich, der unter SQL-92 nicht abgedeckt war, so dass hier zumindest bezogen auf Access 97 alles sowieso proprietär ist.
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db2.doc.relg/bjnvmstr50.htm
Beispiel für JDBC 2.0:
--- Code: ---try {
stmt.addBatch("INSERT INTO employees VALUES (" +
"1000, 'Joe Jones')");
stmt.addBatch("INSERT INTO departments VALUES (260, 'Shoe')");
stmt.addBatch("INSERT INTO emp_dept VALUES (1000, '260')");
int [] updateCounts = stmt.executeBatch();
} catch(BatchUpdateException b) {
System.err.println("Update counts of successful commands: ");
int [] updateCounts = b.getUpdateCounts();
for (int i = 0; i < updateCounts.length; i ++) {
System.err.print(updateCounts[i] + " ");
}
System.err.println("");
}
--- Ende Code ---
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln