Kann sein, dass der Cursor bei Result.updateRow nicht auf der richtigen Zeile steht.
Oder dass du result.UpdateRow nach jedem result.setValue machen mußt.
Sowas wie ODBCResultSet.updateRow gibt natürlich einen Wert zurück. Du könntest damit anfangen, dass du sowas mal logst.
Weiss eigentlich jemand, ob man das generierte SQL irgendwohin gelogt bekommt?
Ich könnte (in Hibernate) nicht anders mit generierten SQL arbeiten und das ist generiertes SQL:
Call result.SetValue(Replace(view.columns(j).title, " ",""), ret(0))
Vielleicht findest du eine Möglichkeit, einfach den insert Befehl zusammenzupuzzeln?
Da du die Spalten der Tabelle und die entsprechenden Feldnamen in Notes eh schon hast?
Und könntest du vielleicht drüber nachdenken, dass man ein paar Kommentarzeilen spätestens dann in code einfügen könnte, wenn man diesen in ein öffentliches Forum postet?
Oder mal einen rationalen Grund nennen, warum du das nicht tust?
Ausserdem macht es in 99.8% der Fälle keinen Sinn die Struktur der Notes Datenbank 1 zu 1 in RDBMS zu übertragen.
Es ist schon ok, die create statements automatisch zu generieren. Nur dann sollte man die händisch ein bischen verändern, um vernünftiges RDBMS design in die Geschichte zu bekommen.
Gruß Axel
Der Klassiker:
oben->
unten:
exit sub
Fehler:
Dim strFehler as String
strFehler = |Fehler in %nameDesAgenten%.initialize | & Error$ & "(" & Cstr(Err) & ") in Zeile: " & Cstr(Erl)
exit sub
Imho ist das sowieso ein Thread, in dem leicht aneinander vorbeigeredet wird. Das sind für mich sowieso die interessantesten. :)
Ralf meint, dass es oft gefährlich ist, wenn man SQL statements als Strings zusammenbaut.
Böse Menschen können das ausnutzen.
table="SELECT * FROM " & Replace(FieldName," ","")
Wenn jetzt in FieldName sowas steht wie
"User; Delete From User";
Dies hätte zur Folge, dass alle Tupel (Datensätze) der User Tabelle gelöscht werden.
Wenn ich dich aber richtig verstanden habe, dann werden diese Select-Statements nicht durch Usereingaben generiert sondern aus dem Modell der Notes-Datenbank.
Unter diesen Bedingungen wäre es nach meiner bescheidenen Meinung wieder i.O. keine prepared Statements zu benutzen.
Deine Inserts/Updates werden sowieso "Prepared Statements"-artig generiert:
For j=0 To view.ColumnCount-1
[...]
Call result.SetValue(Replace(view.columns(j).title, " ",""), ret(0))
[..]
Next j
result.UpdateRow
Dh.-> ein SQL Befehl wird nicht als String zusammengepuzzelt, sondern durch ...hmmm.. sagen wir auf einem höheren Abstraktionsniveau mit dafür spezialisierten Api Methoden.
--> Letztlich wird bei result.UpdateRow ein SQL Befehl gegen Access gesendet, der nicht durch (potentiell gefährliche) String-zusammenpuzzeln, sondern durch das Call result.SetValue(view.columns(j).title, " ", ""), ret(0)
Funktioniert es eigentlich jetzt, wie du dir es vorgestellt hast?
Gruß Axel
Hallo Axel,
Aber das einzigste was ich hinbekommen hab, ist, dass mein Access mir jetzt nur noch Zahlenfelder und keine Textfelder mehr anlegt. ;)
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:
connection.AutoCommit = false ' (connection ist eine ODBCConnection)
connection.commitTransactions
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
Zwar nicht mit Access sondern mit DB/2 aber das sollte uns ja nicht stören.
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:
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("");
}