call RPG mit Parametern aus VB.NET

[Fuerchau]

Nun ja, wie du in meinem Code siehst, habe ich den Datasource-Namen geändert (auf mein verfügbares System), hier solltest du natürlich DEINE Datasource analog zu ADODB angeben .

[Armin]

Manchmal muss man das ganze einfach mal liegen lassen. Am nächsten Morgen kam ich dann auch drauf. War an sich wirklich offensichtlich!
Trotzdem nochmals viiiielen Dank - es funktioniert.

Da hab ich noch eine Frage:
Wie händelt ihr Updates auf der DB2?
Ich denk da auch an Satzsperren. Im RPG hab ich ein Modul, das aufzeigt wer sperrt mit der Möglichkeit eine Break-Msg zu senden.

Lest ihr direkt über SQL oder ist es besser über ein RPG-Programm? Wie sieht es mit der Wartung dann aus? (neue oder geänderte Satzfelder?)
Übergabe als Datenstruktur? Geht das hier? Oder als Array vom Typ Variant?

Ein solcher übersichtlicher Beispielcode ist einfach perfekt.

[Fuerchau]

Remote arbeitet man mit SQL, ins besonders bei .NET (auch Java).
Hier empfehle ich mal Literatur "Visual Basic 2010 von Klaus Löffelmann, 49,00 Euro", da wird auch u.a. auf ADO.NET (gibts aber auch als eigenes Buch) eingegangen.

Satzsperren ist immer ein Problem, deshalb löst man das in .NET ganz anders.
Da man mit SQL arbeitet und ggf. ja nicht die selben Felder geändert werden, wird das Problem damit kleiner.
Allerdings ist die Gefahr dann groß, wenn man eben mit RPG-Programmen mischt.
Da RPG ja immer den gesamten Satz liest und alle Felder dann updatet funktioniert das halt nicht immer wie gewünscht, da vorherige Updates dann zerstört werden.
Zumal die "logischen" Satzsperren dann hier ein Problem darstellen.
Diese Verfahren sind bei ODBC-Zugriffen sehr aufwändig da sie erheblich mehr Zugriffe erfordern und im Absturzverhalten mehr Recovery erfordern.

Im Handbuch ist beschrieben, wie man mit DataTable's und DataAdapater's arbeitet, die zumindest das Problem des konkurierenden Updates verhindern, eine Lösung muss dann allerdings immer noch überlegt werden.
Zusätzlich wäre bei SQL dann Journalisierung auf jeden Fall der bessere Weg um im Falle des konkurierenden Updates z.B. einen Rollback durchzuführen.

Neue Felder sind bei SQL gar kein Problem da sie bei alten Programmen ignoriert werden (ausser bei Select *, was aber kein Problem ist).
Feldänderungen sind dann Zulässig, wenn die Art nicht geändert sondern nur die Ausprägung (Anzahl Stellen) geändert wird, da .NET (wenn keine expliziten Einschränkungen wie Eingabelänhge, programmiert sind) mit beliebigen Felder umgehen kann.

Ich kann das oben genannte Buch nur empfehlen.