Minimalversion aufbauen, Pfad der benutzten DLL ermitteln

[NoPy]

Sehr geehrte Damen und Herren,

ich binde Python in Lazarus/FreePascal ein. Das funktioniert soweit auch, ich kann eine DLL laden und auch auf "selbstgeschriebene" Module zugreifen.

Kurz gesagt: Wenn ich das Programm ausliefere, dann soll es auch funktionieren, wenn auf dem Ziel- Rechner kein Python installiert ist. Ich möchte also die DLL und alle erforderlichen eigenen und fremden Packages in einem Unterverzeichnis mitliefern und das ganze von Lazarus aus ansteuern.

Daraus ergeben sich meine beiden Fragen:
- Was muss ich - außer der dll (python37.dll beispielsweise) noch mitliefern, damit es auf einem "nackten" Rechner läuft?
- Was genau bekomme ich schon inklusive? (Alle Standardmodule von os bis re?)
- Wie bekomme ich heraus, mit welcher der 100 auf meinem Rechner installierten DLLs ich gerade verbunden bin? Gibt es irgend ein print(????), das mir dann ausspuckt: "C:\MeinProgramm\Python\python37.dll"?

Ich hoffe, ihr könnt mir weiterhelfen. Die Frage ist m.E. weniger Lazarus- spezifisch, daher bin ich auf Lazarus weniger eingegangen. Wenn das interessiert, dann einfach fragen.
Vielen Dank schon mal

NoPy

[__deets__]

Du musst alle Bestandteile der Standardbibliothek mitliefern, die - im Zweifel auch transitiv - genutzt werden. Und beim Start des Interpreters kann man zb mit https://docs.python.org/3/c-api/init.html#c.Py_SetPath den Suchpfad für die mitgelieferten Module angeben.

Es ist leider nicht ganz einfach, dieses Modulteilmenge zu bestimmen. Das hier könnte ein Startpunkt sein: https://pypi.org/project/modulegraph/

[NoPy]

1. Das mit SetPath habe ich probiert, das funktioniert ganz gut. Meine eigenen Module bekomme ich so verbraten.
   

   Code: Alles auswählen

   import sys
   sys.path.append(pfad_der_anwendung+"\\python_module")
   

   Ich muss noch probieren, Fremdmodule irgendwo unterzubringen, ohne sie installieren zu müssen (z.B. cx_Oracle, xlwriter ...). Der Nutzer hat i.A. kein Python, keine Ahnung und keine Rechte, etwas zu Installieren.
2. So richtig habe ich noch nicht verstanden, was ich mit modulegraph anfangen kann. Es ist bei mir bereits installiert - wodurch auch immer. Aber die in der Dokumentation beschriebenen Objekte find_modules und modulegraph gibt es nicht, es gibt grundsätzlich nur diese Objekte

   Code: Alles auswählen

   print(dir(modulegraph))
   >>>['__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__', '__spec__', '__version__']
   

   Was muss ich tun?
3. Für eine eventuelle Fehlersuche wäre es noch interessant, ob ich die Version und den Pfad zur "benutzten" Python- dll mir von eben dieser wiedergeben lassen könnte. Da gibt es doch sicher etwas, oder nicht?

Vielen Dank und schönes Wochenende!

[__deets__]

Du musst die Fremdmodule genauso behandeln wie die eigenen und die Standardbibilotheksmodule - sie muessen Teil deines Installers sein, und irgendwohin kopiert werden, und da muessen sie im pfad auffindbar sein.

Und die Dokumentation von modulegraph sagt doch, wie man es benutzt: https://modulegraph.readthedocs.io/en/latest/

Hast du die mal versucht zu finden und zu verstehen?

Deine letzte Frage verstehe ich nicht. Wenn es dir darum geht zu analysieren, welche DLLs von einer Anwendung benutzt werden, dann gibt es dafuer Tools unter Windows, aber mit Python haben die alle nichts zu tun. dependency-walker gab es zB mal, aber das ist alles total kroetig, und ein Grund, warum Entwicklung unter Windows immer so furchtbar nervig ist...

[NoPy]

Du musst die Fremdmodule genauso behandeln wie die eigenen und die Standardbibilotheksmodule - sie muessen Teil deines Installers sein, und irgendwohin kopiert werden, und da muessen sie im pfad auffindbar sein.

Und die Dokumentation von modulegraph sagt doch, wie man es benutzt: https://modulegraph.readthedocs.io/en/latest/

Hast du die mal versucht zu finden und zu verstehen?

Hatte ich noch nicht gefunden, schaue ich mir an.

Deine letzte Frage verstehe ich nicht. Wenn es dir darum geht zu analysieren, welche DLLs von einer Anwendung benutzt werden, dann gibt es dafuer Tools unter Windows, aber mit Python haben die alle nichts zu tun. dependency-walker gab es zB mal, aber das ist alles total kroetig, und ein Grund, warum Entwicklung unter Windows immer so furchtbar nervig ist...

Es geht nicht um irgendeine DLL, sondern um die tatsächlich benutzte Python- DLL. Ich habe auf meinem Rechner mindestens 6 Stück, 2x python 2.7 (32/64 bit), 2x python 3.7 (32/64 bit) und dann noch diverse andere, die beispielsweise mit QGIS oder FreeCAD mitkommen. In Lazarus kann ich im Grunde jede dieser DLLs "connecten" und starten, einige sind compatibel, andere nicht. Ich suche also irgend eine "auto- Identifikation" der benutzten DLL. Wenn ich beispielsweise IDLE starte, dann meldet es sich mit

Code: Alles auswählen

Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 19:29:22) [MSC v.1916 32 bit (Intel)] on win32

- je nachdem, welches der IDLEs ich gestartet habe. Und diese Infos würde ich gern "von innen heraus" abfragen, vorzugsweise auch noch das passende Startverzeichnis der DLL.

Vielen Dank!

[__deets__]

Da hast du ein Problem an anderer Stelle. Wenn du einfach x-beliebige DLLs lädst, dann wird das in einer Katastrophe enden. Du musst die gewünschte DLL sowie die entsprechenden Bestandteile der Standardbibliothek in den Lazarus Projektordner packen. Und zb mit git alles versionieren. Statt dich darauf zu verlassen, dass irgendwo schon die richtige Python Installation rumliegt. Wir haben zb das gesamte CPython git repository als submodul eingebunden, und bauen die DLL immer mit. Dann kann man auch gleich DEBUG oder nicht auswählen, etc, und hat die volle Kontrolle.

[NoPy]

Da hast du ein Problem an anderer Stelle. Wenn du einfach x-beliebige DLLs lädst, dann wird das in einer Katastrophe enden. Du musst die gewünschte DLL sowie die entsprechenden Bestandteile der Standardbibliothek in den Lazarus Projektordner packen. Und zb mit git alles versionieren. Statt dich darauf zu verlassen, dass irgendwo schon die richtige Python Installation rumliegt. Wir haben zb das gesamte CPython git repository als submodul eingebunden, und bauen die DLL immer mit. Dann kann man auch gleich DEBUG oder nicht auswählen, etc, und hat die volle Kontrolle.

Das ist mir schon klar, genau deswegen möchte ich ja wissen, mit welcher DLL ich gerade rede.
Der Plan ist selbstverständlich, die "passende" DLL mit allen erforderlichen Standard-, Fremd- und Projektmodulen mit auszuliefern. Aber ich habe weder den Code für die Python- DLL geschieben noch das entsprechende Lazarus-Package. Und ich habe weder die Kapazitäten noch die Absicht, mich durch alle Quellen zu hangeln. Daher hätte ich eben gern genau diese Selbst- Auskunft der DLL, um sicherzustellen, dass ich nicht durch eigene Fehler, fremde Fehler, Installationsumstände oder irgendetwas die falsche Version am Start habe. Kannst Du mir da helfen?

[__deets__]

Nimm doch einfach eine, die du WILLST. Du musst doch aktiv entscheiden, welche Python Version du verwenden willst. Und dann sicherstellen, dass die auch geladen wird. Was allerdings mehr oder minder automatisch passieren sollte, weil Windows zuerst DLLs aus dem Verzeichnis der EXE lädt.

Wenn du dir das zur Laufzeit anschauen willst, sollte das mit dem Task Manager gehen.

[NoPy]

Nimm doch einfach eine, die du WILLST. Du musst doch aktiv entscheiden, welche Python Version du verwenden willst. Und dann sicherstellen, dass die auch geladen wird. Was allerdings mehr oder minder automatisch passieren sollte, weil Windows zuerst DLLs aus dem Verzeichnis der EXE lädt.

Das ist mir schon klar. Aber eben um sicherzustellen, dass auch wirklich die geladen ist, die ich laden wollte (siehe oben) möchte ich die DLL gern nach ihrem Namen fragen - zur Laufzeit. Ich möchte einfach nur bei evtl. auftretenden Fehlern ausschließen, dass das daran liegt, an einer falschen DLL herumzubasteln.

Wenn du dir das zur Laufzeit anschauen willst, sollte das mit dem Task Manager gehen.

Leider nicht. Ich kann nicht sehen, welche der DLLs zu meinem Programm gehört. UNd selbst wenn, dann wäre das nicht meine Lieblingsvariante. Ich stelle mir eher einen Knopf vor der Art: "benutzte Python- Umgebung anzeigen" und dann geht ein Fenster auf, auf dem möglichst viel steht, anhand dessen ich meine Version identifizieren kann.

Um das mal etwas abzukürzen: Gibt es eine solche Möglichkeit nicht, kennst Du sie nicht oder willst Du sie mir nicht sagen? Eigentlich müsste es irgend so etwas geben, denn IDLE scheint ja auch irgendwelche Infos aus der DLL zu ziehen. Aber vielleicht läuft das auch anders ...

[__deets__]

Mit Verlaub, aber du hast eine dermassen krude Vorstellung davon, was du da gerne haettest, und beschreibst es auch noch schlecht, dass man schlicht nicht auf die Idee kommt, was du da vorhast. Aber Danke dann fuer die Unterstellung, man will dir nicht helfen. Immer gerne genommen.

Wenn man alles am laufen hat, wie du es ja behauptest, dann kann man natuerlich auch einfach "sys.version" auswerten lassen, und dann bekommt man zB eine Antwort. Ich hoffe das ist Antwort genug, denn mehr gibt's auch nicht mehr.

[__blackjack__]

@NoPy: IDLE ist in Python geschrieben, wenn das die von Dir gewünschte Information anzeigt, dann schau doch einfach nach wie das dort programmiert wurde.

[NoPy]

Mit Verlaub, aber du hast eine dermassen krude Vorstellung davon, was du da gerne haettest, und beschreibst es auch noch schlecht, dass man schlicht nicht auf die Idee kommt, was du da vorhast. Aber Danke dann fuer die Unterstellung, man will dir nicht helfen. Immer gerne genommen.

Wenn man alles am laufen hat, wie du es ja behauptest, dann kann man natuerlich auch einfach "sys.version" auswerten lassen, und dann bekommt man zB eine Antwort. Ich hoffe das ist Antwort genug, denn mehr gibt's auch nicht mehr.

Entschuldige bitte, wenn ich Dich gekränkt habe, das war nicht meine Absicht. Aber sys.version war tatsächlich das, was ich gesucht habe, zumindest dem Grunde nach.
Mag sein, dass ich mich missverständlich ausgedrückt habe, auch das war nicht meine Absicht. Ich bin davon ausgegangen, dass Du mich verstanden hast, denn Du hast ja auch keine Rückfragen gestellt.
Ich entwickle seit ca. 10 Jahren keine Software mehr, ich baue nur noch kleine "Tools", die mir und meinen Kollegen die Arbeit erleichtern. Deswegen habe ich zwar manchmal eine Vorstellung der Art "da muss es doch irgendwas geben", aber bisweilen ist es nicht einfach, die entsprechenden Suchbegriffe so zu wählen, dass man etwas passendes herausbekommt.

Ich versuche noch einmal, mein Szenario zu beschreiben, vielleicht gelingt mir das ja jetzt etwas besser. Mit einem Großteil meiner Fragen bin ich ja dank Dir weitergekommen, aber zum Einen will ich Dich nicht im Unklaren lassen, zum Anderen schaut sich vielleicht später jemand diesen Verlauf noch einmal an.

- Ich habe ein paar Module geschrieben, die ganz spezifische Auswertungen in einer komplexen Oracle- Datenbank realisieren. Die Roh- Daten werden mittels SQL beschafft, daraus spezifische Modelle gebaut und parametergesteuert analysiert. Das Ergebnis wird in eine Excel- Tabelle geschrieben. Letztlich wird also eine Funktion aufgerufen in der Form

Code: Alles auswählen

MachWas(parameter1, parameter2, ... parameter0815)

- Da die eigentlichen Nutzer weder über ausreichende python- Kenntnisse verfügen, noch auf ihren Rechnern explizit python installiert haben müssen, soll es eine "exe" geben, die diesen Aufruf kapselt und gewissermaßen das User- Interface bereitstellt. Die Realisierung erfolgt über Lazarus/TPythonEngine. Diese Komponente ist nicht perfekt, lässt sich aber benutzen.
- Damit das ganze funktioniert, muss ich natürlich zu der eigentlichen Wrapper- Exe auch noch

• eine passende Python3x.dll

• die benutzten standard- und Fremdmodule (sys, re, cx_Oracle ...)

• die eigentlichen Projektmodule

mitliefern.

Es wird explizit die python- DLL geladen (wenn ich mich nicht verprogrammiert habe), die im Programmverzeichnis im Unterordner python von mir hingelegt wurde.
Auf den Rechnern existieren allerdings durchaus verschiedenen Python- Versionen, die idR mit Softwareprodukten mitgeliefert werden, z.B. QGIS, FME etc. Ich muss also davon ausgehen, dass in der Pfad- Variable auf diese Versionen verwiesen worden ist. Da ich mich nicht genau genug auskenne (und auch nicht die Zeit habe, das allzuintensiv auszuprobieren oder ein Quellen- Studium zu betreiben), habe ich also die Befürchtung, dass z.B. von mir unbeabsichtigt ein auf dem Rechner vorhandenes Modul benutzt wird (re, os ..., python*.dll), das mit den von mir erstellten Modulen nicht zusammenarbeitet.
Um also einer endlosen Fehlersuche der Art "Bei mir geht das irgendwie nicht" vorzubeugen, möchte ich also einen Knopf einbauen, der anzeigt, mit welcher DLL, mit welchen Modulen mein Lazarus gerade Informationspingpong spielt.

In diesem Zusammenhang ist es auch interessant, welche der Standard- Module sowieso in meiner DLL vorhanden sind. Idealerweise liefere ich nur die DLL, die Excel- und die Oracle- Anbindung, meine spezifischen Module und alles andere (Standardmodule, wie math, re, sys, path ...) ist schon wie von Geisterhand in der DLL drin. Aber eine solche Quelle habe ich nicht gefunden, daher hier dieser Teil der Frage.

Was mir bislang gelungen ist: Die Exe steht, ich kann sowohl die "mitzuliefernde" dll laden, als auch eine explizit auf meinem System vorhandene. Ich kann meine mitgelieferten Module bekanntmachen und benutzen (auf meinem Rechner). Ich weiß, dass ich nun Energie hineinstecken müsste in Virtuelle Umgebungen, Unit- Tests etc, aber das sprengt den Rahmen - insbesondere, weil ich mich damit auf Python- Ebene auch überhaupt nicht auskenne und leider auch keine Zeit habe, mich reinzuarbeiten.

Der letzte Schritt, denn ich gehen möchte, ist, die Pakete zusammenzustellen, die ich mitliefern muss, das alles in ein Archiv zu stopfen und auszuliefern. Mir ist klar, dass einige der Python- Module letztlich auch nur Wrapper sind. Ohne Oracle- Installation funktioniert auch cx_Oracle nicht, gleiches gilt für Excel. Allerdings ist unternehmensweit sichergestellt, dass Oracle installiert ist. Dummerweise manchmal die 32- bit- Variante, manchmal die 64- bit- Variante, das hängt mit den Anforderungen der eingesetzten Software zusammen. Ich komme also nicht völlig aus diesem Try- Error- Konzept hinaus. Es kann also sein, dass ich "liefere", aber aufgrund der "falschen" Installation meine Implementation daneben greift.
Auf meinem Rechner sind sowohl 32- als auch 64- bit- Versionen sowohl von Oracle, als auch von Lazarus und Python installiert.

Nun ist es zumindest schon einmal lang geworden, hoffentlich aber auch klarer.
Es mag sein, dass es elegantere Ansätze gibt und ich lerne auch gern dazu, aber leider muss eben dieses Lernen nebenbei stattfinden, also neben der eigentlichen Aufgabenerfüllung.

Vielen Dank an Dich, __deets__. Du hast mir sehr wohl geholfen.
Und bitte entschuldige das Missverständnis.

[__deets__]

Ich bin manchmal ein bisschen schnell eingeschnappt. Alles gut. Und diese deutlich laengere Erklaerung waere wirklich schon zu Beginn gut gewesen. Denn du suchst eine Loesung fuer ein Problem, dass es zumindest fuer die Python-DLL in diesem Kontext nicht gibt. Das ist auch klar dokumentiert, und mir bekannt gewesen: https://docs.microsoft.com/en-us/window ... plications - haette ich also gleich drauf verweisen koennen.

Der entscheidende Teil ist, das IMMER der erste Ort, an dem gesucht wird, das Verzeichnis ist, in dem die Anwendung liegt. Damit hast du also schlicht nicht das Problem, das du glaubst, das du bekommen koenntest. So lange du die Python-DLL eben per Installer direkt da hinplatzierst, wo sie auch hingehoert. ACHTUNG: das funktioniert NICHT wenn du die aus irgendwelchen Gruenden in einen Pfad packst, der relativ dazu ist. DANN kann man das nicht mehr garantieren. Das solltest du also schlicht nicht tun. Der Satz

Es wird explizit die python- DLL geladen (wenn ich mich nicht verprogrammiert habe), die im Programmverzeichnis im Unterordner python von mir hingelegt wurde.

klingt aber genau so. Muss also geaendert werden.

Und letztlich gilt das auch fuer deinen Oracle-Client. Wenn du kannst, liefer den einfach auch mit (also Oracle's DLL). Wenn das aus irgendwelchen Gruenden nicht geht, ist allerdings essig: es gibt keinen generischen Mechanismus, sowas transparent zu machen. Normalerweise schmiert das Programm einfach ab, wenn die DLL nicht geladen werden kann. Das passiert auch, wenn die Wortbreite nicht passt (also 64 vs 32), und wenn die DLL Symbole nicht enthaelt, die aber vom Code (cx_Oracle in diesem Fall, das ja auch eine DLL darstellt (oder stellte, vielleicht haben die auch auf ctypes gewechselt)) verlangt wird.

Sich dagegen abzusichern gelingt nur, wenn man die DLL haendisch mal laedt, zB per ctypes. Bevor zB cx_Oracle das implizit getan hat (weil dagegen gelinkt). Und dann dynamisch entsprechende Symbole/Funktionen aufruft, in der Hoffnung, dass das alles geht. Das ist aber kein Mechanismus, der irgendwie garantiert ist, sondern nur eine Heuristik. Und ob das mit Oracle geht, kann ich mangels deren Client auch nicht sagen. Meine Karriere hat mich dankenswerterweise weg von dieser Datenbank gefuehrt, ich habe das arbeiten damit immer als fuerchterlich schmerzvoll empfunden (also vor allem das Installer-drumrum etc, Abfragen selbst waren halt SQL).

[NoPy]

Ich bin manchmal ein bisschen schnell eingeschnappt. Alles gut.
Und diese deutlich laengere Erklaerung waere wirklich schon zu Beginn gut gewesen.

Entschuldige bitte. Ich wollte es "auf das Wesentliche" reduzieren, um Euren Aufwand zu begrenzen. Ging wohl nach hinten los

Denn du suchst eine Loesung fuer ein Problem, dass es zumindest fuer die Python-DLL in diesem Kontext nicht gibt. Das ist auch klar dokumentiert, und mir bekannt gewesen: https://docs.microsoft.com/en-us/window ... plications - haette ich also gleich drauf verweisen koennen.

Der entscheidende Teil ist, das IMMER der erste Ort, an dem gesucht wird, das Verzeichnis ist, in dem die Anwendung liegt. Damit hast du also schlicht nicht das Problem, das du glaubst, das du bekommen koenntest. So lange du die Python-DLL eben per Installer direkt da hinplatzierst, wo sie auch hingehoert. ACHTUNG: das funktioniert NICHT wenn du die aus irgendwelchen Gruenden in einen Pfad packst, der relativ dazu ist. DANN kann man das nicht mehr garantieren. Das solltest du also schlicht nicht tun. Der Satz

Es wird explizit die python- DLL geladen (wenn ich mich nicht verprogrammiert habe), die im Programmverzeichnis im Unterordner python von mir hingelegt wurde.

klingt aber genau so. Muss also geaendert werden.

Hab ich gerade reingeschaut. Planmäßig ist das aller Wahrscheinlichkeit nach nicht mein Problem, da ich nicht einmal das dem Zufall überlasse. Ich lade die Python- DLL nicht automatisch beim Programmstart, sondern explizit NACH dem Programmstart. Beim Programmstart ermittle ich zuerst den Aufruf- Pfad und mache dann alles relativ dazu. Daher benötige ich wahrscheinlich/hoffentlich keinen Installer. Ein Installer würde erzwingen, dass ich die Admins bei (fast) jeder Anpassung mit ins Boot holen müsste und das wäre unnötig aufwändig.

Und letztlich gilt das auch fuer deinen Oracle-Client. Wenn du kannst, liefer den einfach auch mit (also Oracle's DLL). Wenn das aus irgendwelchen Gruenden nicht geht, ist allerdings essig: es gibt keinen generischen Mechanismus, sowas transparent zu machen. Normalerweise schmiert das Programm einfach ab, wenn die DLL nicht geladen werden kann. Das passiert auch, wenn die Wortbreite nicht passt (also 64 vs 32), und wenn die DLL Symbole nicht enthaelt, die aber vom Code (cx_Oracle in diesem Fall, das ja auch eine DLL darstellt (oder stellte, vielleicht haben die auch auf ctypes gewechselt)) verlangt wird.

Sich dagegen abzusichern gelingt nur, wenn man die DLL haendisch mal laedt, zB per ctypes. Bevor zB cx_Oracle das implizit getan hat (weil dagegen gelinkt). Und dann dynamisch entsprechende Symbole/Funktionen aufruft, in der Hoffnung, dass das alles geht. Das ist aber kein Mechanismus, der irgendwie garantiert ist, sondern nur eine Heuristik. Und ob das mit Oracle geht, kann ich mangels deren Client auch nicht sagen. Meine Karriere hat mich dankenswerterweise weg von dieser Datenbank gefuehrt, ich habe das arbeiten damit immer als fuerchterlich schmerzvoll empfunden (also vor allem das Installer-drumrum etc, Abfragen selbst waren halt SQL).

Oracle ist nicht wirklich mein Problem. Zum Einen will ich wieder den Admin raushalten, zum Anderen kann ich die Installation wirklich voraussetzen. Es ist lediglich "Roullette" (mit immerhin einer Quote von 1:2), welche Version ich brauche. Der Draht zu meinen "Kunden" ist kurz: Ich stelle ein Zip- Archiv irgendwo ins Netz, diese laden sich das herunter, entpacken das und die Exe geht oder geht nicht. Wenn sie nicht geht, dann muss ich ggf. von 32 auf 64 bit umstellen oder umgekehrt. Es ist eher umgekehrt so: Würde ich die DLLs mitliefern und gar installieren, dann würde vermutlich eines der anderen eingesetzten Programme stören, dann würden aus meinen Admin- Freunden Admin- Feinde werden Klingt vermutlich seltsam, aber wir haben unternehmensweit eine Menge Anwendungen im Einsatz, die auf Oracle aufsetzen. Es ist für die Admins immer eine unterhaltsames Spielchen, Client- DLLs und Fremdsoftware gemeinsam zum Laufen zu bekommen, insbesondere, wenn auf einem Rechner beide Versionen laufen müssen.

Oracle als solches finde ich nicht so schlecht. VARCHAR2 ist ein wenig gewöhnungsbedürftig, aber ansonsten hat es recht nette Features, von SPATIAL- Funktionen bis WINDOW- Functionen, Inline- Views, umfangreiche Nutzersteuerung etc. Und die Mühen der Installation sind glücklicherweise nicht meine Mühen

[__deets__]

Der von mir gepostete Link ist in Bezug auf das wo und wie der DLL sehr explizit. Da steht "If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path."

Solltest du also eine DLL laden, die wiederum eigene Abhaengigkeiten hat, dann sollten die parallel zur EXE liegen, damit du darueber Kontrolle hast. Und um da keine Fehler zu machen, wuerde ich die gleich da alle hinlegen.

Installer ist von mir im weitesten Sinne gemeint. Was auch immer die EXE an die Stelle bugsiert, an der sie liegt.

Oracle ist nicht schlecht in dem Sinne, ich habe tatsaechlich aber noch nie etwas gesehen, dass bei Postgres nicht ebenso gut gewesen waere. Und da haben wir ja noch gar nicht von dem beliebten Einkommensgenerator "Query-Tuning" geredet, das bei Oracle signifikante Kosten durch oft externe Beratung verursacht. Und bei mir den Verdacht naehrt, dass die gar kein Interesse daran haben, das zu verbessern. Denn jeder Berater ist ja auch ein Verkaeufer.

Aber das kann man ja eh nicht aendern.

[NoPy]

Der von mir gepostete Link ist in Bezug auf das wo und wie der DLL sehr explizit. Da steht "If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path."

Solltest du also eine DLL laden, die wiederum eigene Abhaengigkeiten hat, dann sollten die parallel zur EXE liegen, damit du darueber Kontrolle hast. Und um da keine Fehler zu machen, wuerde ich die gleich da alle hinlegen.

Stimmt, das kann ein Problem werden, insbesondere mit Oracle. Das schaue ich mir gleich an.

Oracle ist nicht schlecht in dem Sinne, ich habe tatsaechlich aber noch nie etwas gesehen, dass bei Postgres nicht ebenso gut gewesen waere.

Bei uns werden die meisten Anwendungen jetzt auch auf PostGre/PostGIS umgestellt. Ursachen sind zum Einen die Kosten der Oracle- Lizenzen selbst, aber auch die damit verbundenen Lizensierungsmodelle. Unsere Datenmengen sind an sich gar nicht so klein. Aber sie ändern sich nicht so oft. Ich denke, Oracle braucht man wahrscheinlich wirklich erst, wenn man mehrere Gigabyte je Sekunde transportieren muss.

Und da haben wir ja noch gar nicht von dem beliebten Einkommensgenerator "Query-Tuning" geredet, das bei Oracle signifikante Kosten durch oft externe Beratung verursacht. Und bei mir den Verdacht naehrt, dass die gar kein Interesse daran haben, das zu verbessern. Denn jeder Berater ist ja auch ein Verkaeufer.

Aber das kann man ja eh nicht aendern.

ZUm Glück auch nicht meine Baustelle, zumindest nicht direkt

[__deets__]

Ich denke, Oracle braucht man wahrscheinlich wirklich erst, wenn man mehrere Gigabyte je Sekunde transportieren muss.

Ich bin kein DB-Nutzer mehr, meine Webentwicklungszeiten sind vorbei. Aber ich halte das fuer einen Irrglauben. Nur weil Oracle unfassbar viel Geld kostet, sind die nicht schneller oder besser. Auch nicht im "Grenzbereich". Die Leute, die *wirklich* grosse Datenmengen benutzen, loesen sich dann eher von SQL, statt Unmengen an Lizenzkosten rauszuhauen. Und benutzen Dinge wie DynamoDB oder was auch immer gerade hip ist.