2GB-Limit

[Wendelin Uez]

Kann ich die 2GB-Grenze überwinden, wenn ich den Datenbestand in eine
ActiveX-DLL auslagere, oder läuft auch die ActiveX im selben Adreßraum wie
das Programm und beide gemeinsam dürfen nicht mehr als 2GB haben?

Falls die Auslagerung funktioniert, kann ich dann den Gesamtvolumen durch
Verwendunge mehrere ActiveX quasi beliebig um 2GB erweitern, oder laufen
alle ActiveX-DLL ihrerseits in einem gemensamen 2-GB-Raum?

Als Alternative müssten doch aber auch mehrere einzelne Exe möglich sein,
die jeweils ihre eigenen 2 GB haben. Das sollte doch auf jeden Fall gehen?

Da ich nur jede Menge Daten halten will, darauf aber nur in kleinen Mengen
zugreifen muß, könnte ich die Verzögerung durch Kommunikation der Module
untereinander und den Transfer der Daten der in Kauf nehmen.

[Klaus Ketelaer]

Mich würde mal aus reiner Neugier interessieren, wofür man solch
ein Vorgehen benötigt, bzw. wie man auf solche Gedanken kommt.

In meiner Datenbank stecken viele Millionen Datensätze im mehrstelligen
GB Bereich, und meine Antwortzeiten gehen gegen 0. Bzw. zweistellige ms
Bereiche. Selbst wenn ich die Daten auf meinem Server in Berlin suche.
Zudem behaupte ich einfach mal, dass meine DB die Daten schneller
findet, als ich die in dem von Dir angedachten System finden würde.

Ansonsten würde ich einfach mal nach Ramdisk googeln...

[Wendelin Uez]

> Mich würde mal aus reiner Neugier interessieren, wofür man solch
> ein Vorgehen benötigt, bzw. wie man auf solche Gedanken kommt.

Ganz einfach: Ich will keine Abhängigkeit von einer fremden DLL, aber
trotzdem ausreichend schnell einen Schlüssel finden können. Also halte ich
die Indexdateien im Speicher. Außerdem werkle ich noch mit Bitmaps, dann
könnten die 2GB im Ausbauziel schon mal knapp werden.

Aber die Frage bleibt offen, wie kann ich mehr als 2GB bekommen? Die müssen
ja nicht am Stück sein.

Memory mapped files sind m.W. auch nur innerhalb des 2GB-Raums möglich. Ich
brauche keine drei, vier GB linear, deswegen die Idee mit dem Auslagern in
ActiveX oder Exe.

[Klaus Ketelaer]

Visual Basic ist eine 32 Bit Anwendung und tümmelt sich somit mit
allen anderen 32 Bit Anwendungen im unteren 4 GB Bereich, in dem
meines Wissens Windows ebenfalls werkelt. Willst Du in dem Bereich
dann allen freien Speicher allokieren? So leichtsinnig kannst selbst
Du nicht sein. Das wäre Russisches Roulette.

Ich bin durchaus in der Lage, auch in einer schnöden Datei meine
Schlüssel schnell genug zu finden. Das habe ich früher so gemacht.
In SSD-Zeiten wäre das erst Recht kein Problem. Und eine offene
Datei hält man ja eh mehr oder weniger im Speicher.

Letztendlich ist das, was Du schilderst eine Anwendung für ein DBMS.
Also, wo liegt das Problem? Normalerweise hat doch jeder
Entwickler eh einen Datenbankserver laufen. Oder willst Du mit dem,
was Du da planst, etwa Endanwender beglücken?

Du wirst ja vielleicht mitbekommen haben, dass ich Produkte von
Drittherstellern meide, wie der Teufel das Weihwasser, aber gewisse
Anwendungen braucht man halt, und kann sie nicht selber entwickeln.
Das ist halt bei der datenbank so.

Außerdem nimmt einem die Datenbank unendlich viel Arbeit ab, und
schenkt einem unendlich viele zusätzliche Möglichkeiten. Ich käme
heutzutage niemals auf den Gedanken, irgendwelche Schlüssel selber
im Speicher zu verwalten...

[Dieter Strassner]

Hallo Wendelin,

> Kann ich die 2GB-Grenze überwinden, wenn ich den Datenbestand in eine > ActiveX-DLL auslagere, oder läuft auch die ActiveX im selben
Adreßraum > wie das Programm und beide gemeinsam dürfen nicht mehr als
2GB haben?

Variante 1:
Eine Möglichkeit wäre dies hier:
http://www.vbforums.com/showthread.php?862833-Making-32-bit-VB6-VBA-Code-LARGEADDRESSAWARE

Allerdings:
Alle eingesetzten Komponenten müssen damit klarkommen!

Variante 2:
Stichwort "Free-Threading", dann wäre der Adressraum vervielfacht. Aber
nicht gerade einfach zu handeln.

Variante 3:
Stichwort "vb6 ipc worker" Kommunikation über einen gemeinsamen
Speicherbereich mit anderen (VB6)-Prozessen. Auch nicht gerade trivial

Variante 4:
Eine DB benutzen, die für deine zwecke passt und nicht installeirt
werden muss. Z.B. SqLite

Variante 5:
Prozesskommunikation über Shell-Aufrufe und Rückgabewerte. Kann aber
u.U. Virenscanner auf den Plan rufen.

--
Viele Grüße - Dieter

Strassner Informatik GmbH & Co KG
68623 Lampertheim
Internet: www.strassner.biz

[Ulrich Möller]

Hallo,

Am 11.10.2023 um 10:21 schrieb Dieter Strassner:
> Hallo Wendelin,
>> Kann ich die 2GB-Grenze überwinden, wenn ich den Datenbestand in eine
>> > ActiveX-DLL auslagere, oder läuft auch die ActiveX im selben

...

> Variante 4:
> Eine DB benutzen, die für deine zwecke passt und nicht installeirt
> werden muss. Z.B. SqLite
>
> Variante 5:
> Prozesskommunikation über Shell-Aufrufe und Rückgabewerte. Kann aber
> u.U. Virenscanner auf den Plan rufen.
>
> --
> Viele Grüße  - Dieter
>
> Strassner Informatik GmbH & Co KG
> 68623 Lampertheim
> Internet: www.strassner.biz

Variante 4 und 5 dürften das Problem nicht lösen, weil beides im selber
Prozesskontext abläuft.

Gruß Ulrich

[Klaus Ketelaer]

Am 11.10.2023 um 10:21 schrieb Dieter Strassner:

> Variante 1:
> Eine Möglichkeit wäre dies hier:
> http://www.vbforums.com/showthread.php?862833-Making-32-bit-VB6-VBA-Code-LARGEADDRESSAWARE
>
> Allerdings:
> Alle eingesetzten Komponenten müssen damit klarkommen!
>
> Variante 2:
> Stichwort "Free-Threading", dann wäre der Adressraum vervielfacht. Aber
> nicht gerade einfach zu handeln.
>
> Variante 3:
> Stichwort "vb6 ipc worker"  Kommunikation über einen gemeinsamen
> Speicherbereich mit anderen (VB6)-Prozessen. Auch nicht gerade trivial
>
> Variante 4:
> Eine DB benutzen, die für deine zwecke passt und nicht installeirt
> werden muss. Z.B. SqLite
>
> Variante 5:
> Prozesskommunikation über Shell-Aufrufe und Rückgabewerte. Kann aber
> u.U. Virenscanner auf den Plan rufen.
>

Das Fazit daraus lautet doch am Ende:
Will ich mir keinen Ärger an den Hals holen nehme ich gleich eine DB...

Gruß Klaus