xsharp.eu

Hallo Leute,
mein letzter Kunde, der noch eine größere App einsetzt, die damals mit dem Oracle Developer 2000 Forms & Reports entwickelt wurde, möchte auf seinen Rechnern von Win10 nach Win11 umsteigen (wegen einer anderen App). Der Developer ist 32bit, läuft also nicht mehr auf Win11 nativ (VM wäre da noch eine Alternative, aber nativ ist natürlich sauberer).

Bedingung ist, dass die neue App möglichst von der Oberfläche und vom Verhalten her sich ähnlich verhält. Wer den Oracle Developer kennt, weiß dass dieser sehr effizient mit der tabellarischen Darstellung von Daten arbeitet, dies könnte man wohl mit dem bBrowser soweit abdecken.

Allerdings arbeiten 5 Clients zugleich gegen die Datenbank und der Oracle Developer hat ein sehr ausgereiftes automatisches Record Locking, wo Oracle einen Datensatz bei Bearbeitung automatisch sperrt und bei Commit wieder freigibt. Parallele User erhalten ebenfalls automatisch eine gelockt Meldung wenn sie den gleichen Datensatz bearbeiten möchten.

Wie schauts nun mit X# im Zusammenhang mit diversen Datenbanken (Oracle, MySQL, MariaDb, PostGreSQL, ...) in Bezug auf Record Locking aus, wer hat da bereits Erfahrungen gesammelt? Beim Einsatz von ODBC ist Record Locking wohl nicht in dieser Form machbar, da es eher stateless funktioniert.

LG Franz

Hallo Franz,
32 Bit Applikationen laufen problemlos unter Windows 11 64 Bit - sonst würde auch VO nicht laufen.
Was unter 64 Bit Betriebssystemen nicht mehr geht, sind 16 Bit Applikationen. Das betrifft teilweise die Installationen älterer 32 Bit Applikationen, weil die eine 16 Bit Setup-Routine verwendet haben.
Wolfgang

Hallo Wolfgang,
ich hätte gedacht, dass durch die fehlende 32bit Version auch unter Win11 64bit nichts mehr mit 32bit läuft.
Dann muss ich aber mal testen (lassen), wie es mit dem Oracle Developer unter Win11 64bit aussieht, ob der wirklich keine 16bit Komponenten mehr drin hat.

Danke, Franz

Hallo Franz,
ein reines 64 Bit Windows ist eigentlich nur als Server-System denkbar. Applikationen mit 64 Bit machen eigentlich nur bei großen Speicheranforderungen Sinn. Bei kleineren Applikationen ist das sinnlos, weil sie als 64 Bit mehr Speicher brauchen als mit 32 Bit.
Wolfgang

Ich als "Oracle-Experte" mit X#-Programmen gebe auch noch gerne etwas dazu

32 Bit auf 64-Bit-Rechnern ist wirklich kein Problem.
Entscheidende Fragen sind:
- Was für eine Oracle-Datenbank-Version wird eingesetzt oder soll vielleicht bald durch eine andere ersetzt werden? (aktuelle Version ist jetzt Oracle 19)
- Welche Oracle-Clients verträgt die verwendete Oracle Developer App oder bringt sie einen eigenen Oracle-Client mit?

Ich denke, dass wenn der unterstützte Oracle-Client älter als 11.2.0.3 ist, dann wird es wahrscheinlich Probleme geben auf Windows 11.
Die Clients müssen in gewissen Grenzen zur Datenbank passen. Oracle-12-Clients und neuer unterstützen zum Beispiel nicht Datenbanken älter als Oracle 11, wenn ich mich richtig erinnere.

Falls du selbst eine App schreiben willst/musst:
Wir haben jetzt in unserem Programm Ado.net mit dem Devart-Oracle-Treiber. Früher war das ODBC, aber für eine Neuentwicklung sollte man das vielleicht nicht mehr nehmen. Auf jeden Fall muss man genügend Aufwand einkalkulieren.

Tabelleneditierung mit BBrowser und SQL-Objekten ist sehr aufwendig. Man darf die SQL-Statements erst ausführen, wenn man alles abspeichern will. Also braucht es wahrscheinlich vollgepufferte Serverobjekte, die alles auf Befehl richtig rausschreiben. Auch das ist recht aufwendig.

Recordlocking in Oracle hat nichts mit dem Client-Zugriff wie ODBC zu tun. Entweder macht der Oracle Developer das mit Hilfe von "Select for update"-Statements oder mit selbst definierten Datenbanklocks.

Gruß
Arne

Hallo Arne,
derzeit setzt der Kunde Oracle 10 auf der Serverseite und Net 8 mit dem Oracle Developer (Forms und Reports 6) auf der Clientseite ein, ist schon uralt. Deshalb überlegt er, ob es nicht besser ist, alles neu zu entwickeln. Dafür würde ich dann aber keine Oracle DB mehr verwenden, sondern MySQL, MariaDB, PostGreSQL, etc.

Da aber 5 Clients zugleich mit der App arbeiten, sollte das Locking schon vernünftig funktionieren. Deshalb die Frage wer diesbezüglich mit welcher DB gute Erfahrungen gemacht hat und auch über welchen Connector das gut funktioniert (ODBC, ...).

Was der Oracle Developer im Forms beim RecordLocking absetzt kann ich nicht sagen. Es funktioniert allerdings automatisch: sobald ich in einer Tabelle ein Feld eines Datensatzes ändere ist der Datensatz für andere zur Änderung gesperrt, gelesen mit altem Inhalt kann er werden. Ich kann beliebig viele Datensätze bearbeiten und damit sperren bis ich ein Commit absetze, die Änderungen damit aktiv werden und die RecordLocks aufgehoben.

Ich habe es auch mit dem bBrowser ausprobiert (bSample - Test.exe, Eingaben, automatische Eingabe). Da können mehrere Clients den gleichen Datensatz ändern, der letzte hat gewonnen.

Hier ein kleines Beispiel des Oracle Developer Forms Verhaltens beim RecordLocking anhand einer primitiven tabellarischen Eingabe (die meisten Daten werden in der App in solchen Tabellen direkt bearbeitet):

Der erste User beginnt ein Feld des Datensatzes zu ändern, commited aber noch nicht. Der zweite User möchte den Datensatz auch ändern, bekommt eine Warte-Meldung. Bricht er das Warten ab oder hat der erste User inzwischen seine Änderungen commited, sieht er noch den alten Inhalt. Möchte er nun seine Änderung machen, bekommt er die Meldung dass der Datensatz inzwischen geändert wurde und er die Daten erneut abrufen soll (requery).

Der Kunde möchte dass die neue App soweit wie möglich identisch funktioniert, der bBrowser macht das jedoch nicht so.

Hallo Franz,
Das ist ja gut, wenn der Kunde bereit ist, eine Neuentwicklung zu bezahlen. Wenn er verlangen würde, bei Oracle 10 zu bleiben, dann wäre das im Grunde fast ein "No Go" ohne sinnvolle Zukunft.

Ich nehme an, dass Oracle Developer den folgenden Mechanismus eingebaut hat, den man auch im BBrowser einbauen könnte. Aber das wird recht aufwendig. Im Developer ist es ja nicht eine Browser-Eingabe, sondern eine Formulareingabe mit Cursorbewegungen. Das ist einfacher zu programmieren, weil die Cursorbewegungen einfacher abgefangen werden können.

- Das Programm hält sich ein Array mit den Datensätzen, die geändert wurden.
- Wenn ein Datensatz geändert wird, werden soll, wird ein "Select * from xxx where Primarykey = yyy for Update" für den aktuellen Datensatz gemacht.
- Das "For update" geht nur, wenn niemand anderes bereits diesen Datensatz mit "for update" gelockt hat. Wenn es geht, dann setzt es eine Datensatzsperre.
- Das Programm trägt sich den Datensatz in ein internes Array ein als "Select for Update" gültig ausgeführt.
- Das Programm aktualisiert die Daten in der aktuellen Maske mit den Daten, die aus dem Select gekommen sind und erlaubt das Eintragen von Änderungen.
- Das Programm schreibt die Änderungen raus bei Cursorwechseln ohne Commit bzw. bei bestätigtem Commit.
- Bei Cursorwechseln werden Selects gemacht. Da es dieselbe Session ist, sieht sie die Änderungen von vorher.
- Beim Commit werden automatisch die "Select for Update"-Locks aufgehoben. Das interne Array wird dann freigemacht.
- Man könnte natürlich sich auch das interne Array durch sinnvolle Oracle-Abfragen ersparen.

Man kann in Oracle die offenen Datenbanklocks von allen Sessions abfragen. Damit könnte man eine Analyse machen, ob das so geht.

Die Frage ist, ob man das so nachprogrammieren will. Wir hatten bei uns entschieden, dass keine Statements rausgeschrieben werden dürfen, wenn sie durch Benutzereingaben unterbrochen werden können. Also wird mit gepufferten Serverobjekten gearbeitet und selbst gesetzten Datenbanklocks, wenn notwendig.
Gruß
Arne

Hallo Arne,
ich lasse mir das mal durch den Kopf gehen und spreche dann auch mit dem Kunden darüber, wie weit diese "Goodies" von Oracle wirklich notwendig sind. Zu den "Goodies" zählt nämlich auch die Funktionalität mittels Enter Query / Execute Query.
LG Franz