dynamischer Export zu Access

[Anfaenger]

Hallo erstmal,

Ich hab da so ein "kleines" Problem. Ich bin gerade dabei einen Agenten zu schreiben, der meine Views aus der Datenbank in eine AccessDB schreibt.  Der eine Agent, der die Datenbank und die Tabellen anlegt funktioniert soweit ohne Probleme.
Der andere, der eigentlich die Tabellen mit den Inhalten füllen sollte, läuft auch ohne weiteres durch, nur leider vergisst er dabei fast alle Tabellen. Er schreibt leider nur in 4 von 22 Tabellen etwas rein. Und ich find einfach nicht den Grund, weshalt er dort nichts reinschreibt.
Die Tabellen in Access heißen so wie die Views in LN, nur dass die Leerzeichen herausfefiltert werden.

Ich hoffe, ihr habt da noch ein paar Tipps..

Hier der Agent

Sub Initialize
   Dim strDB As String
   Dim dbq As String
   Dim ConnectionString As String
   Dim con As New ODBCConnection
   Dim qry As New ODBCQuery
   Dim result As New ODBCResultSet
   Dim workspace As New NotesUIWorkspace
   Dim uidoc As NotesUIDocument
   Dim entry As NotesViewEntry
   Dim vwNav As NotesViewNavigator
   Dim table As String
   Dim ret As Variant
   Dim array1(0) As String
   Dim array2(0) As String
   Dim array3(0) As String
   
   array2(0)=" "
   array3(0)=""
   Set uidoc = workspace.CurrentDocument
   Set qry.Connection = con
   Set result.Query = qry
   Set session = New NotesSession
   Set db = session.CurrentDatabase
   
   strDB = Inputbox$("Enter mdb path: ","mdb path", strDB)
   dbq = "; Dbq=C:\" & strDB
   Forall DSN In con.ListDataSources
      If (Instr(1, DSN, "Access") > 0) Then ConnectionString = DSN & dbq
   End Forall
   If Not con.ConnectTo( ConnectionString ) Then
      Messagebox "Could not connect to: " & ConnectionString
      Exit Sub
   Else
      Messagebox "Connected to: " & ConnectionString
   End If
   Set qry.Connection = con   
   
   Vlist= db.views
   K=Ubound(Vlist)
   For i = 0 To K
      If Len(Vlist(i).Name) >0 Then   
         FieldName=Trim(Vlist(i).Name)                   
         Set view=db.GetView(FieldName)
         Set vwnav= view.createViewnav()
         Set entry=vwnav.GetFirstDocument
         table="SELECT * FROM " & Replace(FieldName," ","")
         qry.SQL=table   
         result.Execute
         Messagebox FieldName
         While Not(entry Is Nothing)   
            result.AddRow
            For j=0 To view.ColumnCount-1
               array1(0)=Trim(Cstr(entry.ColumnValues(j)))
               ret = Replace(array1, array2, array3)
               Call result.SetValue(Replace(view.columns(j).title, " ",""), ret(0))
                  
            Next j   
            result.UpdateRow            
            Set entry = vwnav.getnextdocument(entry)                         
         Wend
      End If
   Next i        
   
   result.Close(DB_CLOSE)
   con.Disconnect
End Sub

[flaite]

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:

Code

Call result.SetValue(Replace(view.columns(j).title, " ",""), ret(0))

Will sagen: Daraus entsteht ein SQL Befehl. Wir wissen nur nicht wie er aussieht.

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

[HH]

GetError, GetErrormessage und GetExtendedErrorMessage sind die entsprechenden Methoden um Fehler zu protokollieren. Bau doch einfach mal eine entsprechende Fehlerbehandlung in deinen Code ein. Die Hilfe bietet entsprechende Beispiele hierzu.

Hubert

[flaite]

Der Klassiker:
oben->

Code

on error goto Fehler

unten:

Code

 
exit sub
Fehler: 
Dim strFehler as String
strFehler = |Fehler in %nameDesAgenten%.initialize | & Error$ & "(" & Cstr(Err) & ") in Zeile: " & Cstr(Erl)
exit sub

[Ralf_M_Petter]

Hallo Anfänger!

table="SELECT * FROM " & Replace(FieldName," ","")

Diese Anweisung ist ein absoluter NO NO NO. SQL Statements dürfen nicht über Strings zusammengestopelt werden, da sie dann empfänglich werden für SQL Injections. Das heisst, jemand könnte eine View so benamsen, dass der Sinn deines SQL Statements verändert werden würde. Also immer!!! mit preparedStatements arbeiten oder das Feld wenn wie in diesem Fall notwendig das man mit String Zusammensetzung arbeitet das Feld überprüfen, ob es gültige Werte enthält.

Was an der Routine schief geht lässt sich wohl am besten im Debugger feststellen. Hast du es schon mal debugged und an welcher Stelle verhält es sich ungewöhnlich?

Grüße

Ralf

[Anfaenger]

Hey, vielen Dank für die vielen Einträge.
Stimmt, ich mach wirklich zu wenig(keine) Kommentare. Sollte ich mir wohl mal abgewöhnen.
Dank dem ErrorHandler bin ich dann auf eine Antwort gestolpert(siehe Link weiter unten).
Mit SQL kenn ich mich leider net aus.
Bin auch noch wirklich ein Anfänger, mach das erst seit kurzem.

Anscheinend liegt das Problem bei Access. Bei der Version die ich hab ('97) geht das wohl ganz einfach net:

http://www.manning-sandbox.com/thread.jspa?messageID=5612

Das ist natürlich blöd. Die Alternative die dort steht, lässt aber leider nur ein Eintrag zu. Hab jetzt den ganzen mittag noch damit verbracht dort etwas herauszufinden, wie ich damit mehrere Einträge hinbekomm, aber das ist mir leider net gelungen.

[Ralf_M_Petter]

Hallo Anfaenger!

Habe mir schnell den Link angeschaut. Genau wie es dort beschrieben ist, sollte es funktionieren. Wie kommst du daruf, dass du mit Insert nur einen Satz schreiben kannst. Du kannst eine beliebige Anzahl von Inserts auf eine Tabelle machen. Wobei ich hier aber auf jeden Fall mit preparedStatement arbeiten würde.

Grüße

Ralf

[Anfaenger]

Hallo Ralf

Vielen Dank für den Tipp. Nur steh ich jetzt vor nem anderen Problem: Was ist ein prepared Statement? Ich hab in der Hilfe und online leider nur Zeugs gefunden, was mir leider nicht weitergeholfen hat.
Ich werd jetzt einfach noch ne Weile weitersuchen, vielleicht werd ich noch fündig.

Grüße

Axel

[flaite]

nicht so schlimm.
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:

Code

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

[Ralf_M_Petter]

Hallo Axel!

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. 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.

Zu den SQL injections. Ich halte es auch in dem von dir beschriebenen Szenario nicht für schlau, da es ja offensichtlich da der Export ja offensichtlich für beliebige Notesdatenbanken funktionieren soll. Hier könnte der Benutzer selber eine kleine Datenbank erstellen, die dann Views enthält die SQL Injections ermöglichen.

Das Thema SQL Injections ist wirklich Brand gefährlich. Ich habe mal bei einem Bekannten, der eine PHP Anwendung am laufen hat das kurz demonstriert. Er war ziemlich Baff als ich eine Testtabelle von ihm gelöscht habe nur in dem ich bestimmte Eingaben in eines seiner Webformulare getätigt habe.

Grüße

Ralf

[flaite]

Hallo Ralf,

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.

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?

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.

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,

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

und nach einer Reihe von insert Statements _

Code

connection.commitTransactions

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]

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:

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("");
}

[Anfaenger]

Guten Morgen euch allen..

Vielen Dank für die vielen nützlichen Tipps.
jetzt hab ich es endlich mal geschafft, dass der Fehler nicht gleich beim ersten View kommt, sondern erst beim 15., aber leider schreibt mein Agent pro View nur noch 1 Zeile rein.
Ich hab mir mal gedacht, ich posgte mal wieder den Code, damit ihr ungefähr wisst, wie das so momentan aussieht.

Code:
Sub fill(Conn As String, view As NotesView, tabll As String,maxcol As Integer)
   Dim con As New ODBCConnection
   Dim qry As New ODBCQuery
   Dim result As New ODBCResultSet
   Dim colname As String
   Dim entry As NotesViewEntry
   Dim vwNav As NotesViewNavigator
   Dim table As String
   
   On Error Goto Fehler
   
'hier wird die Verbindung geöffnet   
   If Not con.ConnectTo( Conn ) Then
      Messagebox "Could not connect to: " & Conn   
      Exit Sub
   End If
   
   con.AutoCommit=True 'bei False wird leider nichts geschriebne, deswegen <True>
   Set qry.Connection = con
   
   Set vwnav= view.createViewnav()
   Set entry=vwnav.GetFirstDocument
   i=0
   
'hier wird der Pfad zusammengestückelt   
   While Not(entry Is Nothing)
      table="INSERT INTO " & tabll & " VALUES "      
      table=table & "('"
      For j=0 To maxcol
         colname=Trim(Cstr(entry.ColumnValues(j)))
         If colname="" Then colname="N/A"      
         If j=0 Then      
            table=table & colname & "'"
         Else
            table=table & ",'" & colname & "'"
         End If
      Next j   
      table=table & ")"
      Set entry = vwnav.getnextdocument(entry)     
      qry.SQL=table
   Wend
   
'hier wird reingeschrieben   
   con.CommitTransactions   
   Set result.Query=qry   
   result.Execute            'hier gibts beim ca. 15.View den Fehler <could not complete the requested operation.(720)>                                
   result.close(DB_CLOSE)
   con.Disconnect
   Exit Sub
   
Fehler:
   Messagebox "|Fehler in FillDB.fill |" & Error$ & "(" & Cstr(Err) & ") in Zeile: " & Cstr(Erl)
End Sub

[Ralf_M_Petter]

Na ja das mit jeder Tabelle nur 1 Satz glaube ich relativ klar. Dir fehlt ein ; zwischen den SQL Statements. Ich würde trotzdem nicht alle Insert Into in ein Statement reinschreiben, sondern würde es eventuell in 10er Blöcken abarbeiten. Eventuell ist deine 15te view so groß, dass du an irgendein SQL Limit stosst.

Grüße

Ralf

[Anfaenger]

Guten Morgen alle miteinander..

Ich hatte es ja mal noch so, dass es überall was reingeschrieben hat, aber vielleicht gibt es dort so große Probleme mit Access, weil das nur noch Number-Felder anlegt. Wer weiss.
Danke für den Tipp mit denn ";", hat nur leider net so funktionert wie es sollte. Liegt wohl an den Nummerfeldern in Access, weil die Zahlen Heaxadez.zahlen sind dort jetzt um einiges größer geworden...

Wünsch euch allen nen schönen angenehmen Tag,

Axel

[Anfaenger]

Hab mich jetzt mal endlich wieder dahinter getraut, aber leider weiss ich immer noch nicht, wie ich mehrere Zeilen auf einmal über SQL in die AccessDB reinbekomme. Schaffe das leider immer noch nur mit einer Zeile..

z.b.
qry.SQL=INSERT INTO Name VALUES ('ich', 'du', 'er')

wie muss das denn aussehen, dass ich dort ne zweite Zeile mitreinbekomm?

Ich hoffe, ihr könnt mir da weiterhelfen..

[Ralf_M_Petter]

Ohne Böse zu sein, aber ich habe dir diese Frage schon beantwortet. Falls Access Probleme hat mit mehreren SQL Statements in einem Query dann mache doch einfach jede Zeile in ein eigenes Query in einer Schleife. Dann funktioniert es sicher auch wenn es etwas langsamer ist.

Grüße

Ralf