infobase: EDV - MS-Access


OLE

Diagramme   Quelle: dmt   Datum: 05.2006   nach oben

DIAGRAMME / MSGRAPH / OLE:

Fluch oder Segen ?

Beim Plazieren eines Diagramm-Steuerelementes bzw. Erzeugen eines Diagramm-Auto-Formulares wird man jeweils mit dem Diagramm-Assistenten konfrontiert (mit wem auch sonst?). Der wiederum ließ sich bisher noch in keinem einzigen Fall dazu bewegen, selbst simpelste Daten a'la

Quartal Einnahmen      Ausgaben
1       12.543,00 DM   10.245,00 DM
2       11.345,00 DM   13.004,00 DM
3       10.000,00 DM    8.549,00 DM
4       14.235,00 DM   12.004,00 DM

zu einem vernünftigen Diagramm zusammenzuschustern.
Die Daten erscheinen meistens in Form gleich hoher Balken; die beim Doppelklicken geöffnete MS-Graph-Anwendung zeigt dann auch, daß sie von den zugrundegelegten Daten keine Ahnung hat. Ein Prüfen des SQL-Strings im Eigenschaftenfenster des Steuerelementes ergibt dann auch eine Wahnsinnskonstruktion mit Having, Count, Group und ähnlichen Schweinereien.

Das Einfügen der oberen Tabelle in MS-EXCEL 3.0 führt witzigerweise nach Klicken der Diagramm-Schaltfläche SOFORT zum gewünschten Ergebnis (ohne MS-GRAPH). Im Unglauben über die scheinbare Tatsache, daß MS-GRAPH einfach zu blöd ist, habe ich mich am SQL-String zu schaffen gemacht.

Und siehe da, ein einfaches "SELECT * FROM Test;" reicht aus, um das zu erzeugen, was EXCEL 3.0 sowieso schon kann. Entsprechende Variationen in der Anweisung Forms!Test_Diagramm!OLE1.RowSource="SELECT * FROM Test;" führen zur einer augenblicklichen Anpassung der dargestellten Daten incl. der Achsen.

Die beste Vorgehensweise scheint zu sein, mit der Nicht-Hilfe des Drecks-Assistenten ein Irgendwie-Diagramm zu erzeugen und ihm über Anpassung des SQL-Strings die passenden Daten zu besorgen. Per Doppelklick kann dann MS-GRAPH geöffnet und dem Diagramm dort der letzte Schliff verpasst werden. Per Laufzeit-Änderung des SQL-Stringes kann sich sogar die Diagramm-Legende automatisch anpassen, aber ein direkter Zugriff auf Diagramm-Elemente wie Achsenbeschriftung, Diagrammtyp schien auf den ersten Blick nicht möglich zu sein.

Dennoch konnte über das Ausspionieren der Assistenten-Software einiges in Erfahrung gebracht werden. So kann davon ausgegangen werden, daß so ziemlich alle Eigenschaften des OLE-Diagrammes zur Verfügung stehen, die auch bei gesperrtem Objekt über ein extra Edit-Formulartool eingestellt werden können. -> siehe ole.mdb Formular Test_Diagramm

Übrigens, um das OLE-Objekt per Copy & Paste anderen Anwendungen zugänglich zu machen, muß es enabled werden, was aber nach bloßem Öffnen und Schließen des Formulares zu dem häßlichen "Wollen Sie die Änderungen an ... speichern" führt,
wie wir es schon bei ersten OLE-Tests mit Klangobjekten gesehen haben.

Eingehendere Tests zeigen, daß für das disabled und locked Objekt nur beim Öffnen eine OLE-Aktualisierung stattfindet. Ist es jedoch enabled und nicht locked, dann tritt auch beim Schließen des Formulares eine OLE-Aktualisierung auf, die dann zu der Änderungen-speichern-Meckerei führt.

Dem Problem schien beim BESTEN Willen nicht beizukommen zu sein. Entweder sperren oder freigeben für irgendwelche Aktionen mit in Kauf nehmen der Kack-Frage schienen die einzigen Möglichkeiten. Engagierteste Versuche mit Docmd SetWarnings false oder Fehlerereignisse abfangen, waren fruchtlos. Nach Ausführen einer OLE-Operation am enableden Objekt verhielt sich Access so, als ob eine Änderung im Entwurfsmodus stattgefunden hätte und hat sich beim Schließen des Formulares entsprechend beschwert. Diese Meldung wird intern, bevor irgendwelche offiziellen Access-Formularereignisse (BeimEntladen etc.) eintreten, erzeugt. So konnte das Problem nicht gelöst werden.

Nach eingehendsten Bemühungen zu diesem Thema kann folgendes gesagt werden:

Die OLE-Aktion OLE_COPY kann bei völlig gesperrtem Objekt (Locked=true und Enabled=false) durchgeführt werden. Da das gesperrte Objekt aber nicht fokussierbar ist, muß eine solche Aktion z.B. über eine zusätzliche Schaltfläche per Basic-Code erfolgen (oder man weicht halt temporär auf ein anderes Steuerelement aus) :

    Me!Grafik1.Action = OLE_COPY ( = 4)

Das Ausführen der Aktion OLE_ACTIVATE ist für ein völlig gesperrtes Objekt jedoch nicht möglich.

So, und jetzt kommt's:

Bei der Objekt-Einstellung Enabled=true und Locked=true beschwert sich Access nicht mehr mit 'Wollen Sie die Änderungen ...", sondern mit einer OLE-spezifischen Fehlermeldung: "Das Objekt ist gesperrt, und alle Änderungen, die Sie vorgenommen haben, werden rückgängig gemacht, wenn das Formular geschlossen wird."

Diese Fehlermeldung kann dann in Form_Error wunderbar behandelt werden:

Sub Form_Error (Dataerr As Integer, Response As Integer)

    ' Abfangen des bei OLE-Aktivierung auftretenden Fehlers

    If Dataerr = 2800 Then
       Response = DATA_ERRCONTINUE
    End If

End Sub

Der Clou dabei ist, daß das Objekt fokussierbar ist und die wichtigsten OLE-Funktionen wie OLE_ACTIVATE und OLE_COPY direkt per Doppelklick, per <Strg+c>, per Kontextmenü sowie Code zur Verfügung stehen.

Ole' !

-> ole.mdb

Genau dazu gibt es auch ein schönes und einfaches Beispiel unter dem Begriff "Grafiken austauschen".


Nachschlag:


MSGRAPH - Installation - OLE - Setup:

Wird Access in anderen Umgebungen ausgeführt, in denen es und seine Komponenten nicht installiert wurden, kommt es zu typischen Registry-Fehlern.

Im MSGraph-Fall konnte per Setup-Wizard ein sau-Setup erstellt werden (am besten zum Ausprobieren gleich mit der ole.mdb), allerdings mußten die $WinDir$\msgraph-Daten bereits vorher angelegt werden, da der wizard diese im $WinDir$ sucht. Evtl. ist der Dreck auch noch von einem mitangeklickten OLE-Modul abhängig.

ABER nach einer Office97-CD-Installation, nach der alles friedlich koexistierend zu laufen schien, mußte ich feststellen, daß Access-2.0-OLE-Diagrammobjekte sich nicht mehr darstellen ließen, wenn die Office97-Cd (!) nicht mehr im Laufwerk war. Zu diesem "Wunder von ROM" gibt es bis jetzt keinerlei Erklärung, außerdem habe ich wirklich besseres zu tun.

Zum SQL-String:

Standarddiagramm:

SELECT x-Wert, y-Wert1, y-Wert2 ...


Grafiken austauschen   Datum: 04.2005   nach oben

Gegeben ist der Wunsch, einem sog. Objektfeld ein bestimmtes Objekt zuzuweisen.

Typischer Fall:

Eine Datenbank kennt Produktdaten, die u.a. die Kennzeichnungen einer zum jeweiligen Produkt passenden Grafik enthalten.

Grafiken innerhalb von Access abzulegen, ist nicht immer sinnvoll.
So können Grafiken, die außerhalb von Access in einem Verzeichnis liegen, gepflegt werden, ohne daß die Datenbank-Anwendung dafür angefasst werden muß. Und wie geschickt Access eingebettete Grafikdaten per geheimnisvollsten OLE- und DDE-Quatsch dann letztendlich vermostet, liegt weitgehend im Dunkeln. Wenn man jetzt aus den vorliegenden Daten einen korrekten Dateinamen zusammenbasteln kann und die echten Grafiken per Pfadangabe erreichbar sind, wäre es unheimlich cool, wenn man per einfachem Befehl Pfad und Name einer zu beziehenden Grafik diesem Objektfeld-Steuerelement zuweisen könnte.

Das geht auch (sogar mit Access 2.0), macht aber (wie könnte es anders sein) Ärger, wenn das Ganze nicht wie folgt abläuft:

- Man platziere im Formular ein gebundenes Objektfeld !
  Das ist wichtig, damit kein OLE- und Klassen-Unsinn reingewurschtelt wird.
  Obendrein treten durch erfolgte Zuweisungen keine Formular-Änderungen ein.
- Die Einstellungen sind:
  - Größenanpassung nach Geschmack
  - Klasse sowie Herkunftsdokument und -element leer lassen
  - Objektaktivierung egal
  - Anzeigeart Inhalt
  - Objektaktualisierung manuell
  - Zugelassen OLE-Objektart: Verknüpft
  - Aktiviert: nein
  - Gesperrt: ja
  - In Reihenfolge: nein

Einem solchen Steuerelement können dann mit Aufruf einer folgenden Routine z.B. Grafikdateien zugewiesen werden.

Der Aufruf selbst kann z.B. so aussehen:

  Set_Logo Me!Bild, Me!FocusFeld, "c:\grafiken\test.bmp"

und hier die Prozedur:

Sub Set_Logo (cBild As Control, cFocus As Control, sDatei As String)

    On Error GoTo err_Set_Logo

    DoCmd Hourglass True

    Const OLE_CREATE_LINK = 1

    If sDatei <> "" Then

       cBild.Locked = False
       cBild.Enabled = True

       cBild.SourceDoc = sDatei
       cBild.Action = OLE_CREATE_LINK

       cFocus.SetFocus

       cBild.Locked = True
       cBild.Enabled = False

    End If


exit_Set_Logo:

    DoCmd Hourglass False
    Exit Sub


err_Set_Logo:

    Fehler "Set_Logo"
    Resume exit_Set_Logo

End Sub


OCX später installieren   Quelle: dmt   Datum: 03.2004   nach oben

OCX-Steuerelemente nachträglich einbinden (16-Bit !, KALENDER-Steuerelement):

Entweder SM-mäßig onanieren oder fuck & pray:

* * * *

Eine reine Qual, und nur mit einem Alexandrischem Hieb konnte der gordische Knoten zerschlagen werden:

Notwendige Dateien:

Datei:      Ort:

oc1016.dll  Windows-System-Verzeichnis
xyz.ocx     fast egal
ocx.reg     nur zur Übernahme

Mit viel Kotzen konnte eine gestrippte ocx.reg erzeugt werden, die immer noch über 9kB groß ist. Auf einem fremden Rechner kann diese Datei entweder gedoppelklickt werden oder es muß versucht werden, die Registrierinformationen im Registriereditor von Hand zusammenzuführen.

Eine Sicherheitskopie der reg.dat sei an dieser Stelle in allerhöchstem Maße angeraten.

Allerdings macht es beim 16-Bit-regedit einen Riesenunterschied, ob man ihn einfach nur so oder mit dem Parameter /v startet. Dann erst kommt nämlich das ganze Ausmaß an Tragik zum Vorschein und man sieht, warum die ocx.reg 9kB groß ist. Alle expliziten Pfadangaben müssen natürlich angepaßt werden. Es darf experimentiert werden, ob pfadlose Angaben die Dateien im Anwendungsverzeichnis finden. Ich selbst habe jetzt absolut keine Lust mehr dazu.

Änderungen werden erst nach dem nächsten Neustart wirksam.

Klar, daß auch hier alle 'Informationen' in irgendwelchen Doku's und den teuren Original-Unterlagen bestenfalls in den Ofen geschoben werden können.

* * * *

Wer weniger Zeit oder weniger Vertrauen in die Unzulänglichkeiten der Microsoft-Betriebssysteme hat, kann es auch mal damit versuchen:

In einem lauffähigem Access (2.0, was sonst ?) kann in einem neuen, leeren Formular per Menü Bearbeiten / Objekt einfügen ein Dialogfeld geöffnet werden, daß es erlaubt, OCX-Steuerelemente hinzuzufügen. Wenn das gewünschte Element nicht in der Auswahlliste erscheint, dann eben per Datei-öffnen-Dialog zurechtklicken. Ist das OCX-OLE-Element in der Entwurfsansicht eingefügt, dann das Formular sofort speichern (nicht öffnen !). Am besten Access schließen und danach neu aufrufen. Beim Öffnen des Formulares tritt mit ziemlicher Sicherheit eine schwere Schutzverletzung auf (was sonst ?), Access hängt sich dann vollends auf (warum nicht Bill Gates ?). Wenn danach Windows neu gestartet wird, konnte Access die neuen Funktionalitäten auch in einer anderen Datenbank voll ausspielen.

Nicht gerade elegant, aber überschaubar und risikoarm.


OCX, Ereignisse   Quelle: dmt   Datum: 03.2004   nach oben

OLE-Objekte / OCX-Steuerelemente / Ereignisse:

Problem:
Es soll festgestellt werden, ob ein OLE-Objekt Daten enthält oder nicht.

Abhilfe:
Die Eigenschaft Me.[OLE_Objekt].lpOLEObject enthält einen Long-Wert > 0, wenn Daten enthalten sind.

Ein wenig im Dunkeln bleiben die Unterschiede und damit die Vor- und Nachteile zwischen eingebetteten und verknüpften OLE-Objekten.

Klar scheint zu sein, daß z. B. in ACCESS eingebettete Objekte eben auch physikalisch in ACCESS enthalten sind. Beim HP/VHP-Manager schien sich das mit den Sinnbildern bewährt zu haben. Das kostet zwar Speicherplatz in der MDB-Datei, war aber performance-mäßig der verknüpften Variante bei weitem überlegen.

Bevor der geneigte Leser sich die Mühe macht, den folgenden Roman durchzuarbeiten, soll vorweggenommen werden, daß man anstatt sich mit OLE schwarz zu ärgern, so etwas auch mit einer coolen API-PlaySound-Anweisung höchst einfach, dezent und angenehm abchecken kann -> api.mdb.

Durch Klang-Objekte wird ebenfalls nichts besser. In der Testphase schien das Abspielen einer verknüpften Klangdatei mit weniger Platten-Zugriff verbunden zu sein, als das beim Abspielen eines eingebetteten Klangobjektes der Fall war. Im realen Anwendungsfall ( wenn das gespeicherte Formular 'frisch' geöffnet wurde ) ergab sich wieder das umgekehrte Bild. So weit so gut, als aber das Abspielen des Objektes ( was übrigens auch nicht selbstverständlich ist, da die Standard-OLE-Aktivierung lediglich zum Aufruf der registrierten Abspiel-Software führt, die die doppelgecklickte WAV-Datei dann halt geladen hat ) mit der Anweisung 'Me!Klang.Action = 7' dann im Ereignis FORM_OPEN erfolgen sollte, mußte festgestellt werden, das ACCESS die mit dem Fehler verweigert, daß das OLE-Objekt noch nicht 'initialisiert' worden sei. Als diese Anweisung dann in das Ereignis FORM_CURRENT verlegt wurde, wurden die im Dunkeln liegenden Dinge, die undokumentiert vor, bei oder nach FORM_OPEN abgecheckt werden, auch erledigt und das Klangobjekt war mit geringen Plattenzugriffen zu hören. Das jetzt funktionierende Abspielen des Objektes hatte aber leider zur Folge, daß ACCESS für das OLE-Objekt irgendwelche internen Flags setzte, die eine OLE-mäßige Änderung des Objektes anzeigten. Dies führte beim Schließen des Formulares zu der unerwarteten Meldung ' Wollen Sie die Änderung ... speichern ? '. Auch diese Hürde könnte durch Code-technische Schweinereien evtl. noch genommen werden. Letztendlich hat dann doch die Stimme der Vernunft gesiegt, da ich ja jedesmal, wenn ich in meiner Anwendung einen Klang hören will, meine Stereoanlage anschalten und einstellen muß. Eine Ausgabe einfacher Klänge über den PC-Speaker ist wohl nur für gewitzte Shareware-Programmierer möglich. Unter Windows sehe ich keine Möglichkeit, die Ausgabe umzuleiten, und so einfache Dinge wie 'music (x,y)' oder 'play(...)', wie sie früher von DOS-BASIC oder sogar dem OpenAccess-Compiler beherrscht wurden, scheinen in den 90ern technisch nicht mehr machbar zu sein.

So stirbt schon wieder eine Idee, die Spaß versprach und doch nur das Leiden auf der Welt vergrößerte.

Und wenn denn um jeden Preis eine Melodie auf dem PC-Speaker abgespielt werden muß, kann, solange irgendwelche API-Lösungen unauffindbar bleiben, ja eine eine kleine DOS-Lösung erstellt werden, die dann einfach aufgerufen wird. Das bringts aber auch nicht unbedingt, da hintergrundmäßiges Abspielen mit PLAY (QB45) funktioniert, aber Sirenensounds mittels Schleifen erzeugt werden müssen. Das tut nur mit SOUND, läuft aber dafür nicht im Hintergrund. Pech !

Das OLE-Abspiel-Problem kann mit ein bißchen Klimmzügen doch umgangen werden ->
siehe ole.mdb Formular Play_Wav -> oder ab jetzt per API -> api.mdb.

OCX-Steuerelemente sind schon fast so etwas wie ein Lichtblick. Meistens verfügen sie über eine Reihe zusätzlicher Methoden, Ereignisse und Eigenschaften, die vom Acess-Eigenschaften-Fenster nicht angeboten werden können. Über das Kontextmenü des Entwurfsmodus kann dann ein eigener Eigenschaften-Dialog aufgerufen werden. OCX-spezifische Ereignisse müssen allerdings komplett von Hand in den Code-Bereich des Formulares eingetragen werden, sind aber dafür im Gegensatz zu anderen OLE-Objekten (MS-GRAPH) gut dokumentiert (eigene Hilfe).

Folgende Beispiel-Routine fängt im Code das Ereignis 'Scroll' eines Bildlaufleisten-Elementes ab und übergibt den Wert der Bildlaufleiste 'OLE1' an ein Textfeld 'Wert':

Sub OLE1_Scroll ()

    Me!Wert = Me!OLE1.Object.Value

End Sub


OCX, Gliederungselement   Quelle: dmt   Datum: 03.2004   nach oben

DATENGLIEDERUNG - OLE - OCX - STRUKTURIERUNG

Mal wieder was Positives:

Das Datengliederungs-Steuerelement wurde nach langem und berechtigtem Liegenlassen wieder in die Hand genommen und nach ca. 8 h Programmieraufwand konnten akzeptable Ergebnisse vorgezeigt werden. Die Programmierschnittstelle ist merkwürdig (selbst eine implemtentierte RecordSetClone-Methode muß Unter-Objekten zugewiesen werden, die dargestellten Werte sind direkt gar nicht verwertbar, vieles liegt im Dunkeln), aber immerhin einigermaßen dokumentiert.

Sobald man aber einen Menschen (auch Anwender sind Menschen) auf so ein Ding loslassen will, muß man sich doch um ein paar Sachen mehr kümmern. So schreibt eine kleine Funktion beim Durchlaufen der angezeigten Daten den kompletten Hierarchie-Pfad in die Statuszeile. Vor allem das Öffnen eines zugehörigen Formulares nach Doppelklicken eines Eintrages mit Gruppen-zusammengehörender Auflistung muß mehr als schwer erkämpft werden, ist aber lösbar.

Das Formular Wissen_Hierarchie in dmt.mdb kann als praktische Vorlage benutzt werden.

Noch ausgefeilter wurden die Unwägbarkeiten dieses OCX-Controls im litstg.mdb Formular Standorte_Struktur überwunden.

Mittlerweile können folgende Aussagen gemacht werden:

Die SQL-Anweisung einer Ebene wird in der Praxis häufig eine DISTINCT-Klausel enthalten. Ist eine solche Ebene bereits > 1, muß deren SQL-Statement aber mehr als ein Feld liefern, damit eine noch tiefer liegende Ebene mit mehr als einem Feld verknüpft werden kann. Konstruktionen a'la 'SELECT DISTINCT Name, *' sind unzulässig, aber 'SELECT DISTINCT Name, Vorname, ...' funktionieren sehr wohl.

Zusammen mit der eigenartigen Parameter-Deklaration und den 'verknüpfen nach'-Eigenschaften läuft das dann von der Bedienerseite her.

Anspruchsvoller, weil leider auch interessant ist die Möglichkeit, per

oder Doppelklick ein dazugehöriges Formular auf der Basis der aktuellen Ebenes sowie des aktuellen Wertes anzuzeigen. Ohne jegliche Programmierung öffnet Access das entsprechende Formular in der Einzelblattansicht und springt synchronisierenderweise zum aktuellen Datensatz. Nicht schlecht, aber sehr häufig kommt es vor, daß nicht alle Felder der Tabelle in dem SQL-Statement genannt werden können (z.B. zeige nur die Distinct-Räume). In dem geöffneten Formular werden zwar brav die Datensätze synchronisiert, aber die nicht in der SQL-Anweisung enthaltenen Felder werden als '#Name' moniert. Das bringt's nicht und deswegen ist wie üblich wieder mal hacken angesagt. Obendrein muß mit jeder tiefergehenden Ebene der SQL-String incl. Parameter sowie die 'verknüpfen nach'-Angabe um ein Feld erweitert werden. Im litstg-Beispiel ist die Reihenfolgen der Nennung dergestalt, daß die Statuszeilen-Infofunktion noch tut und für die zu verarztenden Ebenen, die teilweise nur einzelne Felder enthalten, trotzdem eine überschaubare und ziemlich allgemeine Routine für die verschiedenen Ebenen ausreicht.

Die wesentlichen Ebenen-Eigenschaften:


Name: Raum

Datenherkunft: SELECT DISTINCT Raum FROM Standort_Zuordnungen

Verknüpfen nach: nix

-

Name: Regal

Datenherkunft: PARAMETERS P1 Text; SELECT DISTINCT Regal, Raum FROM Standort_Zuordnungen WHERE Raum=P1

Verknüpfen nach: Raum

-

Name: Fach

Datenherkunft: PARAMETERS P1 Text, P2 Text; SELECT DISTINCT Fach, Regal, Raum FROM Standort_Zuordnungen WHERE Raum=P1 AND Regal=P2 ORDER BY Fach DESC

Verknüpfen nach: Raum; Regal

-

Name: Ordner

Datenherkunft: PARAMETERS P1 Text, P2 Text, P3 Text; SELECT Ordner, Fach, Regal, Raum FROM Standort_Zuordnungen WHERE Fach=P1 AND Regal=P2 AND Raum=P3 ORDER BY
Ident

Verknüpfen nach: Fach; Regal; Raum


Der Code, der Ebenen-sensitive SQL-Kriterien generiert, sieht aus wie folgt:

Sub OLE1_RequestFormOpen (Cancel As Integer, Level As Integer)

    Dim OB As Object    ' Datengliederungs-Steuerelement
    Dim LI As Object    ' LevelInfo-Objekt
    Dim ORS As Object   ' Datensatzgruppenobjekt

    Dim i As Integer, j As Integer, s As String

    Set OB = OLE1.Object
    Set LI = OB.LevelInfos

    ' **** Abbruch, wenn kein FormName angegeben wurde ****

    If LI(Level).Formname = "" Then
       Cancel = True
       Exit Sub
    End If

    ' **** oder Level mit nativen Access-Öffnungseigenschaften ****

    If Level = 4 Then Exit Sub

    ' *************************************************************

    Set ORS = OB.GetRecordsetClone(Level)

    j = Level

    For i = 0 To Level - 1
        j = j - 1
        s = s & LI(i + 1).Name & "='" & ORS(j) & "' AND "
    Next i

    s = Left$(s, Len(s) - 5)

    Cancel = True

    DoCmd OpenForm LI(Level).Formname, A_FORMDS, , s

End Sub

Ziemlich kryptisch, aber es tut.


Probleme   Quelle: dmt   Datum: 03.2004   nach oben

Bei dem Versuch, daß OLE-Feld eines neuen Datensatzes auf Vorhandensein eines Inhaltes hin zu überprüfen, schien sich die OLE-Objekt-Eigenschaft 'lpOLEObject' anzubieten.

Wurde ein Objekt zugewiesen, geht eine Überprüfung

'>0'
in Ordnung. Wurde allerdings kein Objekt zugewiesen, geht jeglicher Vergleich in die Hose.

Keine der bekannten Methoden a'la IsNull, IsEmpty etc. kann angewendet werden, da in diesem Fall ein ganz besonderer Fehler Nr. 2196 auftritt, den MS-ACCESS mit folgender Meldung quittiert:

'Die Einstellung für diese Eigenschaft kann nicht angenommen werden. Die Eigenschaft könnte in dieser Ansicht nicht verfügbar sein, oder ein Fehler könnte aufgetreten sein.'

ACCESS könnte auch Scheiße sein.

nach oben
zur Startseite dieses Webangebotes zur infobase-Hauptseite