Oracle ORA-12637 XE7/FireDAC

[jmy0123445]

Hallo,

mit dem Client nutzen wir immer den Instant Client im Application Verzeichnis, um das "veroraclen" zu vermeiden . Aktuell nutzen wir den 19er 32 Bit Instant Client. Aber wie gesagt, habe ich auch mal so ziemlich alles zwischen 11 und 19 getestet.

Die DevArt sind aktuell keine Alternative. Führt hier zu weit, aber die BDE war damals überall im Code verteilt. Ich war schon froh, dass das mit FireDAC gut funktioniert hat. Ist auch keine kleine Anwendung. Da ist mal mit eben nichts getan. Die Migration verspricht zwar eine 100%ige Umsetzung. Aber wenn wir alles testen müssen, sind wir da schon ein paar Wochen weiter.

PS: schön zu hören, dass andere mit den Oracle Install Allüren auch gewisse Erfahrungen gesammelt haben

[jobo]

OT

Es ist auch schön zu hören, wie es in der Cloud so gehen kann.

Ohne Schadenfreude: rechnet sich sowas? Monetär? Qualitativ? Uptime? Responsetime?
Oracle ist ja nicht der Einzige, der super Gewinnzuwächse in der Cloud verzeichnet.
Und wenn man die Datenbank Datensatz für Datensatz verkauft, ist es ja auch kein Wunder.
Erinnert etwas an die Idee von Dr. Oetker, Backpulver in 5g Tüten zu verkaufen- nein, ich bin nicht neidisch. Und dann ist da noch der Plattformbetreiber, der die Hand aufhält.

Und das sind nur die Kosten, kein Support usw.. Wobei ich vermute, dass man "normalen" Oracle Support haben könnte, wenn man wollte und zahlte und das dann auch zu den heimischen Bürozeiten.

Warum tut man sich das an bei einem Altsystem? Bei einem neuen kann es ja bessere Gründe geben.

[jmy0123445]

Auch OT
@jobo
Zunächst mal: die Sätze hätte ich auch schreiben können. Bin aber Dienstleister. Ich kann den Kunden auf diese Probleme hinweisen, was ich getan habe. Aber es ist nicht meine Entscheidung.

Zitat:

Ohne Schadenfreude: rechnet sich sowas? Monetär? Qualitativ? Uptime? Responsetime?

Frag mal das Management, was aktuell so ziemlich alles was vorhanden ist, in die Cloud legt.
Im speziellen Fall: falls die Applikation langsamer wird, schlucken das in der Regel die Subs. Der "eigentliche" Kunde (product owner) nutzt das Produkt nur, um Daten nachzuschauen und engineered damit nicht mehr.
Die (gesamt-)Kosten kann ich nicht beurteilen. Das aktuelle Rechenzentrum ist alt und wird halt geschlossen. man braucht keinerelei eigene Hardware mehr, keine eigene IT mehr usw. Letztlich kann ich das nicht beurteilen

Zitat:

Und das sind nur die Kosten, kein Support usw.. Wobei ich vermute, dass man "normalen" Oracle Support haben könnte, wenn man wollte und zahlte und das dann auch zu den heimischen Bürozeiten.

Großer internationaler Konzern. Es wird alles nur noch ausschließlich monetär beurteilt. Und im IT Bereich spart man halt. Ob es dann woanders mehr kostet ist doch dem Entscheider egal. Andere Kostenstelle. Er hat die Kosten in seinem Bereich erfolgreich gesenkt. Hier sind ganz viele lokale (gute) IT-ler nicht mehr da, die waren sicherlich teuer. Ganzes Rechenzentrum entsorgt. Da kommt was zusammen.
Der Rest wird dann in Projekten versteckt. Wenn dann die Anlage vielleicht statt 100.000.000 EURO 1.000.000 EUR mehr verschlingt, weil die Tools alle bescheiden sind: whoe cares. Problem des Projektes.
Es ist ein gesellschaftliches Problem. Es wird nur noch ausschließlich auf Kosten geschaut. Hauptsache mein Budget/Projekt/Arbeitspaket ist perfekt. Aber hier könnte ich ganze Romane drüber verfassen. Hat sich auch sehr gewandelt in den letzten 25 Jahren. Neue Entwicklungsprojekte habe ich quasi gar nicht mehr in meinem Umfeld. Also da, wo man wirklich mal was wirklich! Neues macht/erfindet. Immer nur abgekupfert und weiterentwickelt. Aber die Kaufleute haben gewonnen, auch wenn das alles seine Berechtigung hat. Durch das Homeoffice wird das Ganze noch befeuert werden.

[jmy0123445]

Ein kleines Update.

Aktuell bin ich noch nicht sicher. Ich habe im Applikationsverzeichnis den neuesten 32 bit Oracle Treiber abgelegt - das war vorher auch schon der Fall. Wir haben aber nie eine lokale sqlnet.ora zusammen mit dem Instant Client verwendet.
Dieses haben wir jetzt ergänzt. die sqlnet.ora sieht aktuell jetzt folgendermassen aus:
DISABLE_OOB=ON
SQLNET.INBOUND_CONNECT_TIMEOUT=120
SQLNET.OUTBOUND_CONNECT_TIMEOUT=120
SQLNET.SEND_TIMEOUT=120
SQLNET.RECV_TIMEOUT=120
TCP.CONNECT_TIMEOUT=120

Der Parameter DISABLE_OOB=ON hat eine deutliche Verbesserung gebracht. Auch wenn ich es mir nicht aktuell erklären kann, kommen seit der Ergänzug des DISABLE_OOB und den Timeout Parametern keine Fehlermeldungen mehr. Wobei sich die Timeout Parameter noch gar nicht erklären (da in Sekunden).
Ich werde das nochmal aus anderen Netzwerken probieren.

Aktuell ist es nur eine Zwischenstand.

[jmy0123445]

Hallo,

nur noch mal eine kurze Info. In der Tesdatenbankumgebung scheint alles jetzt mit den genannten Parametern zu arbeiten, genau wie im Post zuvor beschrieben.
Es wird jetzt eine Produktivumgebung erzeugt, hier werden wir nochmal alle Funktionen des Programms im Detail testen, sofern das bei dem Monolithen möglich ist .
Der Test in der Produktivumgebung wird in Summe ein paar Wochen in Anspruch nehmen. Sollten sich noch Updates ergeben, werde ich die an dieser Stelle ergänzen. Ansonsten sehe ich zum jetzigen Zeitpunkt das Thema als gelöst an.