<\/p>\n
Wenn Sie längere Texte in Tabellen abspeichern oder umfangreiche Binärdaten in OLE-Feldern ablegen, so bläht das die Datenbank auf. Während dieser Umstand bei lokalen Datenbanken heutzutage kein Problem mehr darstellt, sieht die Sache in einer Mehrbenutzerumgebung und Netzwerkzugriffen auf Backends schon anders aus. Hier sollte der Traffic minimiert werden. Da macht sich dann die Komprimierung solcher Datenfelder gut, was zu verbesserter Performance führen kann.<\/b><\/p>\nKomprimieren von Memo- und Long-Binary-Feldern<\/h2>\n
über das Für und Wider von in Tabellen abgelegten Binärdaten oder Textdokumente möchten wir hier nicht diskutieren. Das kann ganz einfach immer wieder vorkommen, und es gibt ganze Serverumgebungen, die davon weidlich Gebrauch machen, wie etwa der Microsoft Sharepoint-Server<\/b>. Die Kompression dieser Daten verkleinert die Datenbankdateien und hilft dabei den benötigten Traffic zu den Clients zu verringern. <\/p>\n
An sich ist derlei bereits in Access integriert. Der Datentyp Anlage<\/b> (Attachment<\/b>) speichert binäre Daten und komprimiert diese nach Bedarf, wobei Microsoft sich weitgehend darüber ausschweigt, bei welchen Dateitypen dies zutrifft und welcher Kompressionsalgorithmus zum Einsatz kommt. Nicht jeder ist jedoch ein Freund von Anlage-Feldern<\/b>, denn aufgrund des dahinter liegenden versteckten Datenmodells, welches sich tatsächlich von Sharepoint<\/b>-Technik ableitet, ist der programmtechnische Umgang mit ihnen recht komplex. Zudem können Anlagefelder nicht in Access 2003<\/b> oder früher angezeigt oder ausgelesen werden. Deshalb macht sich die Binärspeicherung in OLE-Feldern<\/b>, bei denen es sich ja schlicht um Long-Binary<\/b>-Felder handelt, besser.<\/p>\n
Das Thema ist nicht neu. Bereits in der Ausgabe 3\/2007<\/b> (Shortlink 466<\/b>) von Access Im Unternehmen<\/b> wurde es behandelt, weshalb wir an dieser Stelle zusätzlich auf jenen Beitrag verweisen. Dort wurde die Komprimierung über eine externe Komponente erreicht, eine zlib-DLL<\/b>, auf die im VBA-Projekt verwiesen wird. Darauf kann verzichtet werden, wenn man sich der wenig beachteten Windows-API-Funktion RTLCompressBuffer<\/b> bedient, die eigentlich zur Abteilung der Treiber-APIs gehört. Sie erreicht, vor allem bei Texten, durchaus vergleichbare Kompressionsraten. Der eingesetzte Algorithmus ist eine LZ<\/b>-Variante (Lempel-Ziv<\/b>).<\/p>\nEinschub: Kompression in Anlagefeldern<\/h2>\n
Da Microsoft keine komplette Liste veröffentlicht, welche Dateitypen in Anlage-Feldern<\/b> denn nun komprimiert werden und welche nicht, sondern pauschal behauptet, dass jene unbearbeitet blieben, die bereits hinlänglich komprimiert sind, wie etwa JPG<\/b>, haben wir einen einfachen Test unternommen. Eine Datenbank enthält eine Tabelle, die wiederum nur ein Anlage-Feld<\/b> enthält. Wir messen die Dateigröße dieser ACCDB<\/b> nach dem Hinzufügen jeweils einer<\/b> größeren Datei eines bestimmten Typs und anschließendem Komprimieren und Reparieren<\/b> der Datenbank. Verwendet werden gängige Dateitypen. Steigt die Größe der ACCDB<\/b> um die Größe der hinzugefügten Datei, so dürfte die interne Kompression der Anlage<\/b> nicht angesprochen haben. Die folgende Tabelle gibt Auskunft über das Ergebnis:<\/p>\n Zu erwähnen wäre noch, dass dezidiert Dateien verwendet wurden, die entweder viele Wiederholungen enthalten oder viele Null-Bytes<\/b>, sich mithin also gut komprimieren lassen. Das Ergebnis ist eindeutig: Die Kompression scheint zum Glück der Default zu sein. Nur ausgewählte Dateiformate, wie JPG, ZIP, DOCX, XLSX<\/b>, die bekannterweise schon eine Kompression aufweisen, werden ausgenommen. Erstaunlich hoch sind die Kompressionsraten. Dass etwa eine RTF-Datei<\/b> von über 4 MB<\/b> Größe auf intern 120 kB<\/b> schrumpft, war nicht zu erwarten. Als Datei-Container eignen sich Anlage-Felder <\/b>demnach hervorragend. <\/p>\n Leider kann der in diesem Beitrag vorgestellte Algorithmus da nicht mithalten. Dennoch hat er seine Existenzberechtigung, und wir führen kurz die Vorteile gegenüber Attachments<\/b> auf:<\/p>\n Das Modul mdlCompression<\/b> der Beispieldatenbank enthält eine Funktion CompressRTL<\/b>, die Byte-Arrays<\/b> komprimieren kann. Ihr Code ist in Listing 1 abgebildet. Er nutzt einige Windows-API-Funktionen<\/b>, die im Modulkopf deklariert sind (Listing 2). Der Rückgabewert ist wiederum ein Byte-Array <\/b>mit den komprimierten Daten. Das Ganze kommt ausgesprochen übersichtlich daher. Auf die genaue Funktion des Codes und der API-Aufrufe<\/b> möchten wir hier gar nicht eingehen. Einige Hinweise dürfen jedoch nicht fehlen.<\/p>\n Listing 1: Die fünf im Modul verwendeten API-Funktionen<\/span><\/b><\/p>\n So enthält die Prozedur keine Fehlerbehandlung. übergeben Sie etwa ein undimensioniertes Array, so kracht es gleich in der ersten Zeile beim Ausdruck UBound<\/b>. Auch sonst werden die Rückgabewerte der API-Funktionen nicht ausgewertet, so dass Fehlfunktionen nicht offensichtlich sind. Allerdings dürfte es auch kaum einen Fall geben, der hier bei einem ordnungsgemäßen Byte-Array zu Fehlern führt. Kritisch ist bestenfalls der Wert der von RTLCompressBuffer<\/b> zurückgelieferten Variablen retSize<\/b>, die angibt, wie viele Bytes im Ergebnis enthalten sind. Er wird im weiteren Verlauf dazu verwendet, um das Ergebnis-Array binOut<\/b> neu zu dimensionieren. Hier könnten rein theoretisch Werte anfallen, die über den erlaubten Wertebereich hinausgehen. Uns ist bei allen Tests derlei aber nicht untergekommen.<\/p>\n Nun möchten Sie möglicherweise nicht Byte-Arrays komprimieren, sondern Strings. Das macht eine Konvertierung dieser erforderlich. Gegeben sei etwa ein Text in der Variablen sText<\/b>, der zu komprimieren wäre. Dann verwenden Sie die VBA-Funktion StrConv<\/b>:<\/p>\n StrConv<\/b> kann Strings in Byte-Arrays überführen und umgekehrt. Da es sich bei VBA-Strings immer um Unicode<\/b> handelt, ist der Parameter vbFromUnicode<\/b> der richtige. Er macht aus dem String quasi ein ANSI-Byte-Array<\/b>. Dieses übergeben Sie dann der Funktion CompressRTL<\/b> des Moduls.<\/p>\n Mit dem komprimierten Byte-Array<\/b> selbst können Sie wenig anfangen. Entweder speichern Sie es in einer Datei ab, oder im OLE-Feld <\/b>einer Tabelle. Es reicht dazu schlicht die Zuweisung an den Feldinhalt. Beispiel:<\/p>\n Einstmals mussten Sie sich mit der Methode AppendChunk<\/b> eines DAO<\/b>-Felds herumschlagen und in einer Schleife Teile des Byte-Arrays (Chunks<\/b>) hinzufügen. Das ist veraltet. Die unmittelbare Zuweisung funktioniert bei heutigen Rechnerausstattungen auch bei großen Byte-Arrays. Das Limit liegt lediglich beim dem DAO-Thread<\/b> zugewiesenen RAM-Bereich (Heap Working Set<\/b>) der Datenbank-Engine.<\/p>\n Nun möchten Sie die komprimierten Daten wieder in ihrer ursprünglichen Form zurückgewinnen. Das übernimmt die Dekompressionsroutine DecompressRTL<\/b> des Moduls, welche in Listing 3 abgebildet ist. Auch ihr Umfang ist erfreulich gering. Ihr Aufruf entspricht genau dem für die Komprimierprozedur CompressRTL<\/b>. Sie holen sich etwa die komprimierten Daten aus der Tabelle und erhalten die entpackten im Rückgabe-Array, welches Sie wieder per StrConv<\/b> in einen Text verwandeln:<\/p>\n <\/p>\n Listing 3: Routine DecompressRTL zum Entpacken der Byte-Arrays<\/span><\/b><\/p>\n Die String-Umwandlung passiert nun natürlich umgekehrt mittels des Parameters vbUnicode<\/b>. Haben Sie nicht Texte, sondern Dateien komprimiert, so entfällt die Umwandlung per StrConv<\/b> selbstverständlich jeweils.<\/p>\n Das bisher Gesagte zusammengefasst mündet in ein praktisches Beispiel, das so auch in der Demo-Datenbank vorhanden ist. Alle Dateien eines bestimmten Verzeichnisses sollen komprimiert als Datensätze in einer Tabelle abgespeichert werden. Die dafür vorgesehene Routine ImportFiles<\/b> finden Sie in Listing 4, die Entwurfsansicht der Zieltabelle in Bild 1.<\/p>\n Bild 1: Aufbau der Tabelle tblBinary zum Abspeichern binärer Daten<\/span><\/b><\/p>\n Listing 4: Einlesen der Dateien eines Verzeichnisses in die Tabelle<\/span><\/b><\/p>\n Das Feld Path<\/b> nimmt den vollständigen Pfad zur Datei auf, FileLen<\/b> deren Größe in Bytes. BLOB<\/b> ist der Container für die unkomprimierten Daten. In der Praxis würden Sie dieses Feld nicht verwenden, da im OLE-Feld CompressedBLOB<\/b> die komprimierten Daten stehen, aus denen die Datei ja wiederhergestellt werden kann. LenCompressed<\/b> speichert die Größe der komprimierten Daten und Ratio<\/b> als Gleitkommazahl das Kompressionsverhältnis. Diese beiden letzten Felder könnte man ebenfalls weglassen, da sich LenCompressed<\/b> aus CompressedBLOB.FieldSize<\/b> ergäbe, und Ratio<\/b> aus Selbigem geteilt durch FileLen<\/b>. Die beiden Felder sind hier integriert, damit man in der Datenblattansicht der Tabelle gleich eine übersicht über den Erfolg der Kompression hat.<\/p>\n Die mit einigen Beispieldateien gefüllte Tabelle zeigt Bild 2. Sie ist absteigend nach dem Kompressionsfaktor (Ratio<\/b>) sortiert. Es wird deutlich, dass sich bei den Bilddateien und PDFs keine nennenswerte Kompression einstellt. Notepad.exe<\/b> verringert sich immerhin um ein Viertel. Bei den Bitmaps hängt der Faktor vom Bildinhalt ab. Je mehr gleichfarbige Flächen enthalten sind, desto besser die Kompression. Dasselbe gilt für Excel- und Word-Dokumente. Die Kompression ist umso erfolgreicher, je mehr Wortdoppelungen in diesen Dokumenten enthalten sind. <\/p>\n Bild 2: Die Datenblattansicht der Tabelle tblBinary zeigt den Ursprung der Dateien neben zusätzlichen Angaben zur Kompression<\/span><\/b><\/p>\n Wir haben alle Dateien zum Vergleich einmal in ZIP-Archive<\/b> gepackt. Die resultierenden Dateigrößen sind allgemein deutlich geringer, als die mit der API-Funktion erreichten. Das Nonplusultra stellt der Algorithmus von RTLCompressBuffer<\/b> also nicht dar. Dafür arbeitet die Funktion allerdings außerordentlich schnell. Möchten Sie etwa eine größere Zahl von Office-Dokumenten in Ihrer Datenbank ablegen, so verkleinern Sie deren Dateigröße mit der Kompression etwa um den Faktor zwei bis drei.<\/p>\n Doch zurück zur Prozedur in Listing 4<\/b>. Hier werden in einer Do While<\/b>-Schleife alle Dateien des als Parameter übergebenen Verzeichnisses sDir<\/b> abgearbeitet und in die Tabelle tblBinary<\/b> übertragen. Auf diese ist, nachdem sie in der ersten Zeile geleert wird, ein Recordset rs<\/b> geöffnet. Eine Datei liest die Open-Anweisung<\/b> im Binärmodus in das Byte-Array bin<\/b> ein. Dessen Inhalt wird direkt dem Feld BLOB<\/b> als Wert übergeben, während das Feld CompressedBLOB<\/b> das Ergebnis des Funktionsaufrufs der weiter oben behandelten Prozedur CompressRTL<\/b> speichert. Das Einlesen der Dateien von Bild 2 dauerte bei uns mit dieser Routine gerade einmal eine Sekunde! Die Kompression selbst geschah jeweils in wenigen Millisekunden.<\/p>\n Für das Abspeichern komprimierter Textdateien gibt es in der Beispieldatenbank eine gesonderte Tabelle tblTexte<\/b> (s. Bild 3) und eine eigene Prozedur ImportTexts<\/b>. Diese Routine entspricht ziemlich genau der vorigen Prozedur ImportFiles<\/b>, weshalb ein Listing entfallen kann. Nur benutzt sie zusätzlich die Konvertierung des eingelesenen Byte-Arrays per StrConv<\/b> in Strings. Die wiederum nimmt das Memo-Feld Text<\/b> auf, während die komprimierten Daten in das OLE-Feld CompressedText<\/b> gelangen. Der Aufbau der Tabelle entspricht ansonsten dem von tblBinary<\/b>.<\/p>\n Bild 3: Aufbau der Tabelle tblTexte zum Abspeichern langer Texte<\/span><\/b><\/p>\n Als Dateitypen kommen hier nicht nur TXT<\/b>-Dateien infrage, sondern etwa auch CSV<\/b>– oder XML<\/b>-Dateien. Das Ergebnis eines Tests von ImportTexts<\/b> mit einigen Dateien zeigt Bild 4. Die Kompressionsraten liegen hier naturgemäß etwas höher, als bei den reinen Binärdateien, da Texte in der Regel mehr wiederholte Byte-Folgen enthalten. Zusätzlich kommt hier die Komprimierung von Unicode<\/b>-Texten ins Spiel, die ja eine Menge von Null-Bytes enthalten, falls es sich um UTF-16<\/b> handelt. Unser Test-Set enthielt allerdings nur ANSI<\/b>– oder UTF-8<\/b>-Dateien, und dennoch kamen wir auf Kompressionsraten von bis zu etwa fünf – ein durchaus brauchbarer Wert.<\/p>\n Bild 4: Die Datenblattansicht der Tabelle tblTexte zeigt den Ursprungstext der Textdateien neben zusätzlichen Angaben zur Kompression<\/span><\/b><\/p>\n Nun befinden sich die Texte komprimiert in der Tabelle und könnten anschließend dekomprimiert wieder als Dateien abgespeichert werden. Eher aber möchten Sie sie wahrscheinlich direkt in einem Formular anzeigen. Das Formular frmTexte<\/b> der Beispieldatenbank zeigt, wie das geht. Im Entwurf (Bild 5) finden Sie normale Textboxen für alle Felder der Tabelle vor. Eine Ausnahme bildet das große ungebundene Textfeld im Detailbereich, bei welchem es sich eben um keine Access-Textbox<\/b> handelt, sondern um ein ActiveX-Steuerelement, die MS Forms-Textbox<\/b>. Sie hat einen gewichtigen Vorteil: Sie kann auch Texte darstellen, die länger als 65 kB lang sind. Zudem wirkt sich bei ihr das Scrollen unmittelbar in der Anzeige aus. Sie könnten das Textfeld übrigens auch über die Eigenschaft Steuerelementinhalt<\/b> direkt an ein Tabellenfeld binden, was hier natürlich entfällt, weil der Text nach Dekomprimierung aus dem Feld CompressedText<\/b> kommen soll, was erst der VBA-Code erledigt. Leider ein Nachteil der MSForms-Textbox<\/b>: Sie können ihr nicht das Feature Verankern<\/b> mit Dehnen verpassen. Wenn Sie das tun, so wirkt sich eine Vergrößerung zur Laufzeit nicht wie erwartet aus: Statt den Textbereich zu vergrößern, zoomt das Steuerelement lediglich den Text!<\/p>\n Bild 5: Im Entwurf des Formulars frmTexte kommt eine MS-Forms-Textbox zur Textanzeige zum Einsatz<\/span><\/b><\/p>\n Den Code zum Dekomprimieren der Daten bringen Sie im Ereignis Beim Anzeigen<\/b> (Form_Current<\/b>) unter:<\/p>\n Zunächst wird hier ermittelt, ob es sich beim angezeigten Datensatz um einen neuen handelt (NewRecord<\/b>) oder, ob das Feld CompressedText<\/b> leer ist. In diesen Fällen wird der Inhalt der Textbox gelöscht und die Routine verlassen. Andernfalls nimmt das Byte-Array bin<\/b> den Feldinhalt auf und liefert ihn an die Funktion DeCompressRTL<\/b> des Moduls mdlCompression<\/b>. Dessen Rückgabewert ist zwar ebenfalls ein Byte-Array, Sie können dieses aber interessanterweise direkt der Eigenschaft Text<\/b> des Steuerelements ctlText<\/b> zuweisen. Bei einer Access-Textbox wäre dies nicht möglich. Das abschließende Setzen des Werts für SelStart<\/b> stellt sicher, dass sich der Text-Cursor nach dem Laden des Textes am Anfang steht. Ohne diese Aktion würde sich das Ende des Textes im Steuerelement abbilden.<\/p>\n Zur Laufzeit präsentiert sich das Ganze dann wie in Bild 6. Rechts oben im Formular finden Sie einen Button cmdLoad<\/b> vor, über den Sie eine neue Textdatei in einen neuen Datensatz laden können. Die ausgelöste Ereignisprozedur steht in Listing 5. Sie ist im Grunde analog zur Prozedur ImportsTexts<\/b> und ImportFiles<\/b> (Listing 4<\/b>) ausgeführt, sodass auf weitere Erläuterungen hier verzichtet werden kann. Nur so viel: Die zu ladende Datei steht in der Variablen sFile<\/b>, nachdem eine Hilfsroutine OpenFileDlg<\/b> in mdlCompression<\/b>, die sich den Office-Filedialog<\/b> zunutze macht, sie ermittelt hat. Am Ende der Prozedur erfolgt noch ein Requery<\/b>, ein Neuladen der Datensatzquelle des Formulars, weil dies wiederum Form_Current<\/b> auslöst und den dekomprimierten Text damit zur Anzeige bringt. Requery<\/b> führt leider zu einem Sprung zum ersten Datensatz des Formulars, weshalb die letzte Zeile über MoveLast<\/b> zum eben angelegten Datensatz zurückspringt.<\/p>\n Bild 6: Das Formular frmTexte auf Basis der tblTexte zeigt zur Laufzeit die dekomprimierten Texte an<\/span><\/b><\/p>\n Handelt es sich bei den komprimierten Daten nicht um Texte, so nützt Ihnen eine Textbox zur Anzeige wenig. Ein Anlage-Steuerelement<\/b> kann ja auch nur Texte und Bilder anzeigen und startet bei anderen Dateitypen nach Doppelklick das mit dem Typ im System assoziierte Programm. Derlei könnten wir hier auch implementieren, doch die Wahl fällt wieder einmal auf das Webbrowser-Steuerelement<\/b>, da der Internet Explorer<\/b> nicht nur Texte und Bilder anzeigen kann, sondern über Plug-Ins auch andere MIME<\/b>-Typen, wie etwa PDFs oder Videos. Dennoch können die dekomprimierten Daten dem Webbrowser nicht einfach als Binär-Stream verabreicht werden, sondern müssen zunächst als Dateien vorliegen. An einer Umwandlung ins Dateisystem kommen Sie hier nicht herum.<\/p>\n Das übernimmt im Formular frmBinary<\/b> wieder das Ereignis Form_Current<\/b> (Listing 6). Die komprimierten Daten aus CompressedBLOB<\/b> der Tabelle tblBinary<\/b> speichert das Byte-Array bin<\/b>. Die per DecompressRTL<\/b> erhaltenen Originaldaten nimmt das Ergebnis-Array binOut<\/b> auf. Dessen Inhalt wird in eine im Binärmodus geöffnete Datei gespeichert. Der Name dieser Datei (sTempFile<\/b>) ergibt sich aus dem Datenbankpfad plus temp<\/b> plus der zuvor aus dem in Path<\/b> abgelegten vollen Pfad ermittelten Dateiendung in sExt<\/b>. Zu dieser nun erstellten Datei navigiert das Webbrowser-Steuerelement ctlWeb<\/b> und zeigt sie an. Zusätzlich nimmt die im Kopf des Moduls deklarierte Collection<\/b>-Variable colFiles<\/b> den Namen dieser Datei auf. Denn beim Blättern durch die Datensätze können sich ja so mehrere Dateien wie temp.jpg<\/b>, temp.pdf<\/b>, oder temp.xls<\/b> im Datenbankpfad ansammeln, die beim Entladen des Formulars besser wieder mit Kill<\/b> gelöscht und bereinigt werden:<\/p>\n Listing 6: Erstellen temporärer Dateien für den Webbrowser-Inhalt<\/span><\/b><\/p>\n Ein Beispiel, wie sich das Formular zur Laufzeit mit einer aus den komprimierten Daten geladenen PDF<\/b>-Datei präsentiert, zeigt Bild 7. Es hängt vom PDF-Plugin<\/b> ab, welche Gestalt das Dokument dabei annimmt. Hier ist das übrigens nicht der Adobe Reader<\/b>, sondern das Plugin des nach unserem Dafürhalten besseren PDF-XChange Viewers <\/b>(Tracker Software<\/b>).<\/p>\n Bild 7: Das Formular frmBinary verwendet zur Anzeige der dekomprimierten Dateien einen Webbrowser<\/span><\/b><\/p>\n Natürlich können Sie Bilder, wie beschrieben, auch mit dem Webbrowser anzeigen oder die jeweils temporär exportierte Bilddatei in ein Bildsteuerelement laden. Das ist indessen nicht unbedingt erforderlich, wenn Sie die dekomprimierten Daten direkt in ein Bildobjekt umwandeln und einem MS Forms-Image-Steuerelement<\/b> zuweisen.<\/p>\n Diese Aufgabe ist nicht trivial und kann nur mit-hilfe einer Handvoll von API-Funktionen gelöst werden. Wir verwenden dafür einige Prozeduren auf Basis des Windows-GDIPlus<\/b>, die Sie im Modul mdlGDIPlus<\/b> der Beispieldatenbank vorfinden. Sie übergeben der Funktion ArrayToPicture<\/b> ein Byte-Array mit den Bilddaten, die genau der Ursprungsdatei entsprechen müssen. Erlaubte Typen sind BMP<\/b>, JPG<\/b>, PNG<\/b>, TIFF<\/b> und ICO<\/b>. Zurück erhalten Sie ein StdPicture<\/b>-Objekt, das Sie unmittelbar an die Eigenschaft Picture<\/b> eines MS Forms-Images<\/b> leiten können. Umgesetzt ist dies im Formular frmBilder<\/b> (s. Bild 8). Beim Laden des Formulars muss zunächst die GDIPlus-Session<\/b> initialisiert werden (InitGDIP<\/b>-Prozedur):<\/p>\n Bild 8: Das Formular frmBilder zur Anzeige der dekomprimierten Bilddaten verwendet ein Forms-Image<\/span><\/b><\/p>\n Die in der Folge bearbeiteten GDI<\/b>-Objekte sollten beim Entladen des Formulars bereinigt werden:<\/p>\n Der Kern ist dann aber die Ereignisprozedur Beim Laden<\/b>, welche die komprimierten Daten aus der Tabelle holt, sie per DecompressRTL<\/b> in ihren Ursprung zurückverwandelt und das resultierende Byte-Array über ArrayToPicture<\/b> in ein Bildobjekt überführt, welches dem Steuerelement ctlImg<\/b> zugewiesen wird:<\/p>\n<b>Dateityp Größe Datei Größe DB Kompression, ca.\r\n(leer) - 404 kB -\r\ntxt 3770 kB 1020 kB 6-fach\r\ndoc 3430 kB 1778 kB 2,5-fach\r\nrtf 4400 kB 524 kB 37-fach\r\nxls 3640 kB 1020 kB 6-fach\r\nppt 3800 kB 676 kB 14-fach\r\npdf 3280 kB 2208 kB 1,8-fach\r\nbmp 4130 kB 516 kB 34-fach\r\njpg 4300 kB 4752 kB keine\r\ntiff 3050 kB 3305 kB keine\r\nxml 3830 kB 992 kB 6,5-fach\r\nkml 6650 kB 540 kB 49-fach\r\ncsv 3380 kB 740 kB 10-fach<\/pre>\n
\n
Kompressionsroutine<\/h2>\n
Private <\/span>Declare Function RtlGetCompressionWorkSpaceSize _\r\n Lib \"NTDLL\" (ByVal Flags As Integer<\/span>, WorkSpaceSize As <\/span>_\r\n Long, UNKNOWN_PARAMETER As Long<\/span>) As Long<\/span>\r\nPrivate <\/span>Declare Function NtAllocateVirtualMemory Lib _\r\n \"ntdll.dll\" (ByVal ProcHandle As Long<\/span>, BaseAddress As <\/span>_\r\n Long, ByVal NumBits As Long<\/span>, regionsize As Long<\/span>, ByVal _\r\n Flags As Long<\/span>, ByVal ProtectMode As Long<\/span>) As Long<\/span>\r\nPrivate <\/span>Declare Function RtlCompressBuffer Lib \"NTDLL\" _\r\n (ByVal Flags As Integer<\/span>, ByVal BuffUnCompressed As Long<\/span>, _\r\n ByVal UnCompSize As Long<\/span>, ByVal BuffCompressed As Long<\/span>, _\r\n ByVal CompBuffSize As Long<\/span>, ByVal UNKNOWN_PARAMETER As <\/span>_\r\n Long, OutputSize As Long<\/span>, ByVal WorkSpace As Long<\/span>) As <\/span>_\r\n Long\r\nPrivate <\/span>Declare Function RtlDecompressBuffer Lib _\r\n \"NTDLL\" (ByVal Flags As Integer<\/span>, ByVal BuffUnCompressed _\r\n As Long<\/span>, ByVal UnCompSize As Long<\/span>, ByVal BuffCompressed _\r\n As Long<\/span>, ByVal CompBuffSize As Long<\/span>, OutputSize As <\/span>_\r\n Long) As Long<\/span>\r\nPrivate <\/span>Declare Function NtFreeVirtualMemory Lib _\r\n \"ntdll.dll\" (ByVal ProcHandle As Long<\/span>, BaseAddress As <\/span>_\r\n Long, regionsize As Long<\/span>, ByVal Flags As Long<\/span>) As Long<\/span><\/pre>\nDim <\/span>bin() As Byte<\/span>\r\nDim <\/span>binRet() As Byte<\/span>\r\nbin = StrConv(sText, vbFromUnicode)\r\nbinRet = CompressRTL(bin)<\/pre>\nDekompressionsroutine<\/h2>\n
Dim <\/span>rs As <\/span>DAO.Recordset\r\nSet<\/span> rs = CurrentDb.OpenRecordset(\"Binaertabelle\")\r\nrs.Edit ''''oder rs.AddNew<\/span>\r\nrs!OleFeld1.Value = binRet\r\nrs.Update<\/pre>\nPublic Function <\/span>DeCompressRTL(Buffer() As Byte<\/span>) As Byte<\/span>()\r\n Dim <\/span>LSize As Long<\/span>, memSize As Long<\/span>\r\n Dim <\/span>binOut() As Byte<\/span>\r\n \r\n LSize = UBound<\/span>(Buffer) * 12.5\r\n ReDim binOut(LSize)\r\n RtlDecompressBuffer 2& Or &H100, VarPtr(binOut(0)), LSize, _\r\n VarPtr(Buffer(0)), 1& + UBound<\/span>(Buffer), memSize\r\n If (memSize > 0) And (memSize <= UBound<\/span>(binOut)) And _\r\n (memSize < 2000000) Then\r\n ReDim Preserve binOut(memSize - 1)\r\n DeCompressRTL = binOut\r\n End If<\/span>\r\nEnd Function<\/span><\/pre>\nDim <\/span>rs As <\/span>DAO.Recordset\r\nDim <\/span>bin() As Byte<\/span>\r\nDim <\/span>binRet() As Byte<\/span>\r\nDim <\/span>sText As String<\/span>\r\nSet<\/span> rs = CurrentDb.OpenRecordset(\"Binaertabelle\")\r\nbin = rs!OleFeld1.Value\r\nbinRet = DecompressRTL(bin)\r\nsText = StrConv(binRet, vbUnicode)<\/pre>\nDateien komprimiert im OLE-Feld<\/h2>\n
![\"Aufbau](\"..\/fileadmin\/_temp_\/2018_01\/tblBinary_DS.png\")
<\/p>\nSub <\/span>ImportFiles(Byval sDir As String<\/span>)\r\n Dim <\/span>sFile As String<\/span>\r\n Dim <\/span>bin() As Byte<\/span>\r\n Dim <\/span>rs As <\/span>DAO.Recordset\r\n Dim <\/span>F As Integer<\/span>\r\n \r\n CurrentDb.Execute \"DELETE FROM tblBinary\"\r\n Set<\/span> rs = CurrentDb.OpenRecordset( _\r\n \"SELECT * FROM tblBinary\", dbOpenDynaset)\r\n sFile = Dir(sDir & \"\\*.*\")\r\n Do While<\/span> Len<\/span>(sFile) > 0\r\n F = FreeFile\r\n Open sDir & \"\\\" & sFile For Binary As <\/span>F\r\n ReDim bin(LOF(F) - 1)\r\n Get F, , bin\r\n Close F\r\n \r\n With<\/span> rs\r\n .AddNew<\/span>\r\n !Path = sDir & \"\\\" & sFile\r\n !FileLen<\/span> = FileLen<\/span>(sPath)\r\n !BLOB.Value = bin\r\n !CompressedBLOB.Value = CompressRTL(bin)\r\n !LenCompressed = !CompressedBLOB.FieldSize\r\n !Ratio = Round(!FileLen.Value \/ _\r\n !LenCompressed.Value, 3)\r\n .Update\r\n End With<\/span>\r\n sFile = Dir\r\n Loop<\/span>\r\n rs.Close\r\nEnd Sub<\/span><\/pre>\n![\"Die](\"..\/fileadmin\/_temp_\/2018_01\/tblBinary.png\")
<\/p>\nTexte komprimiert im OLE-Feld<\/h2>\n
![\"Aufbau](\"..\/fileadmin\/_temp_\/2018_01\/tblTexte_DS.png\")
<\/p>\n![\"Die](\"..\/fileadmin\/_temp_\/2018_01\/tblTexte.png\")
<\/p>\nTextboxen mit dekomprimierten Texten füllen<\/h2>\n
![\"Im](\"..\/fileadmin\/_temp_\/2018_01\/frmTexte_DS.png\")
<\/p>\nDim <\/span>bin() As Byte<\/span>\r\nIf <\/span>Me.NewRecord Or Len<\/span>(Me!CompressedText.Value) = 0 Then<\/span>\r\n Me!ctlText.Value = \"\"\r\n Exit Sub<\/span>\r\nEnd If \r\nbin = Me!CompressedText.Value\r\nMe!ctlText.Object.Text = DeCompressRTL(bin)\r\nMe!ctlText.Object.SelStart = 0<\/pre>\n![\"Das](\"..\/fileadmin\/_temp_\/2018_01\/frmTexte.png\")
<\/p>\nDekomprimierte Dateien im Formular anzeigen<\/h2>\n
Private <\/span>colFiles As <\/span>New<\/span> VBA.Collection\r\nPrivate Sub <\/span>Form_Current()\r\n Dim <\/span>bin() As Byte<\/span>, binOut() As Byte<\/span>\r\n Dim <\/span>F As Integer<\/span>\r\n Dim <\/span>sExt As String<\/span>\r\n Dim <\/span>sTempFile As String<\/span>\r\n bin = Me!CompressedBLOB.Value\r\n binOut = DeCompressRTL(bin)\r\n sExt = Mid<\/span>(Me!Path.Value, _\r\n InStrRev<\/span>(Me!Path.Value, \".\"))\r\n F = FreeFile\r\n sTempFile = CurrentProject.Path & \"\\temp\" & sExt\r\n Open sTempFile For Binary As <\/span>F\r\n Put F, , binOut\r\n Close F\r\n DoEvents\r\n Me!ctlWeb.Object.Navigate2 sTempFile\r\n On Error Resume Next<\/span>\r\n colFiles.Add sTempFile, sExt\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>Form_Unload(Cancel As Integer<\/span>)\r\n Dim <\/span>itm As Variant<\/span>\r\n On Error Resume Next<\/span>\r\n For Each itm In colFiles\r\n Kill CStr(itm)\r\n Next<\/span> itm\r\nEnd Sub<\/span><\/pre>\n![\"Das](\"..\/fileadmin\/_temp_\/2018_01\/frmBinary.png\")
<\/p>\nUmwandeln von komprimierten Bilddaten in Bilder<\/h2>\n
![\"Das](\"..\/fileadmin\/_temp_\/2018_01\/frmBilder.png\")
<\/p>\nPrivate Sub <\/span>Form_Load()\r\n InitGDIP\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>Form_Unload(Cancel As Integer<\/span>)\r\n ShutDownGDIP\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>Form_Current()\r\n Dim <\/span>bin() As Byte<\/span>, binOut() As Byte<\/span>\r\n bin = Me!CompressedBLOB.Value\r\n binOut = DeCompressRTL(bin)\r\n Set<\/span> Me!ctlImg.Object.Picture = ArrayToPicture(binOut)\r\nEnd Sub<\/span><\/pre>\n