A2007 - Aktionsabfragen und Anlagefelder
Manuela Kulpa
mit bedauern musste ich feststellen, dass Anlagefelder (Mehrfachwertfelder)
sowohl bei einer "normalen" Tabellenerstellungsabfrage als auch bei einer
"normalen" Anfügeabfrage nicht zugelassen sind (programmiertechnisch habe ich
es noch nicht ausprobiert). Gibt's irgendeinen Trick, wie man diese
Problematik umgehen kann?
Vielen Dank fürs Lesen & Antworten
Manuela
Peter Doering
Manuela Kulpa wrote:
> mit bedauern musste ich feststellen, dass Anlagefelder (Mehrfachwertfelder)
> sowohl bei einer "normalen" Tabellenerstellungsabfrage als auch bei einer
> "normalen" Anfügeabfrage nicht zugelassen sind (programmiertechnisch habe ich
> es noch nicht ausprobiert). Gibt's irgendeinen Trick, wie man diese
> Problematik umgehen kann?
Es gibt Moeglichkeiten, Komplexitaet je nach Anforderung. Wenn du nur einen
Wert einfuegen willst, dann so:
INSERT INTO Tab1 ( DeinMVF.Value )
VALUES ('WasAuchImmer')
Gruss - Peter
--
Ich beantworte keine Fragen per Email.
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
Manuela Kulpa
merci für deine Antwort
"Peter Doering" wrote:
> Es gibt Moeglichkeiten, Komplexitaet je nach Anforderung. Wenn du nur einen
> Wert einfuegen willst, dann so:
>
> INSERT INTO Tab1 ( DeinMVF.Value )
> VALUES ('WasAuchImmer')
>
Nun ja, bei dieser Version muss ich ja dann auch Datensatzweise vorgehen
(schade eigentlich). Ich glaube, dann nehme ich doch eher ein Recordset2. Ich
vermute mal, dass man Dateien nicht mit dieser Variante einfügen bzw.
ersetzen kann, oder?
Viele Grüße
Manuela
Peter Doering
Manuela Kulpa wrote:
> "Peter Doering" wrote:
>
>> Es gibt Moeglichkeiten, Komplexitaet je nach Anforderung. Wenn du nur einen
>> Wert einfuegen willst, dann so:
>>
>> INSERT INTO Tab1 ( DeinMVF.Value )
>> VALUES ('WasAuchImmer')
>>
>
> Nun ja, bei dieser Version muss ich ja dann auch Datensatzweise vorgehen
> (schade eigentlich). Ich glaube, dann nehme ich doch eher ein Recordset2.
Ich hatte deshalb ja geschrieben "je nach Anforderung". Und du hattest
nicht geschrieben, was du genau haben wolltest.
> Ich vermute mal, dass man Dateien nicht mit dieser Variante einfügen bzw.
> ersetzen kann, oder?
Mach eine konkrete Aufgabenstellung, dann sehen wir weiter.
Manuela Kulpa
es tut mir leid, wenn ich mich mit meiner letzten Äußerung wohl ein wenig
missverständlich ausgedrückt habe. Es geht mir nicht darum, VBA-mäßig auf
Anlagefelder zuzugreifen bzw. zu bearbeiten. Dies war nur eine kleine
Bemerkung am Rande. Der Sinn und Zweck von Aktionsabfragen ist ja, auf einen
Schlag Daten zu verändern, ohne umständlichen Code zu schreiben.
"Peter Doering" wrote:
> Ich hatte deshalb ja geschrieben "je nach Anforderung". Und du hattest
> nicht geschrieben, was du genau haben wolltest.
>
> Mach eine konkrete Aufgabenstellung, dann sehen wir weiter.
Es geht mir generell um Tipps & Tricks, wie man oben genannte Einschränkung
ggf. ohne VBA-Bordmittel umgehen kann, da ich diese Info für meine Kurse
benötige und auf solche Fragestellungen eingerichtet sein muss (diese Frage
z.B. kam gestern in einem Grundlagenseminar auf). Wenn dies grundsätzlich
nicht realisierbar ist, reicht mir die Antwort: Sorry, es geht nicht. Damit
gebe ich mich schon zufrieden!
Also, nichts für ungut :o). Ich wünsch dir ein schönes WE und übersende
viele Grüße
Manuela
Peter Doering
Manuela Kulpa wrote:
> "Peter Doering" wrote:
>
>> Ich hatte deshalb ja geschrieben "je nach Anforderung". Und du hattest
>> nicht geschrieben, was du genau haben wolltest.
>>
>> Mach eine konkrete Aufgabenstellung, dann sehen wir weiter.
>
> Es geht mir generell um Tipps & Tricks, wie man oben genannte Einschränkung
> ggf. ohne VBA-Bordmittel umgehen kann, da ich diese Info für meine Kurse
> benötige und auf solche Fragestellungen eingerichtet sein muss (diese Frage
> z.B. kam gestern in einem Grundlagenseminar auf). Wenn dies grundsätzlich
> nicht realisierbar ist, reicht mir die Antwort: Sorry, es geht nicht. Damit
> gebe ich mich schon zufrieden!
Kein Problem. Kernaussage: Es GEHT per SQL, wenn auch nicht so einfach wie
bisher. Wenn du ein konkretes Beispiel brauchst, melde dich halt wieder.
Sascha Trowitzsch
"Manuela Kulpa" <Manuel...@discussions.microsoft.com> schrieb im
Newsbeitrag news:D3D0FA67-7627-4803...@microsoft.com...
> Hallo Peter,
>
> es tut mir leid, wenn ich mich mit meiner letzten Äußerung wohl ein wenig
> missverständlich ausgedrückt habe. Es geht mir nicht darum, VBA-mäßig auf
> Anlagefelder zuzugreifen bzw. zu bearbeiten. Dies war nur eine kleine
> Bemerkung am Rande. Der Sinn und Zweck von Aktionsabfragen ist ja, auf
> einen
> Schlag Daten zu verändern, ohne umständlichen Code zu schreiben.
Ich möchte das nochmal aufgreifen.
Zunächst ist mir auch nicht klar, wo genau du mit Aktionsabfragen
Anlagefelder ändern öder hinzufügen willst. Der Witz ist ja, dass ein
Anlagefeld selbst eine Art eingebundene Tabelle ist, die mehrere Datensätze
enthalten kann. An diese internen Tabellen kommt man IMHO von außen nicht
ran. In MSYSObjects sind diese Tabellen zwar unter länglichen Namen, die von
GUIDs abgeleitet zu sein scheinen, aufgeführt, aber über die
TableDefs-Auflistung lassen Sie sich nicht ansprechen - "Unbekannt".
Dann ist auch die Frage, welche Art von Aktionsabfrage du genau ausführen
möchtest. Es ist ein Unterschied, ob du eine Anfüge-, Aktualisierungs- oder
Erstellungsabfrage ausführen willst:
- Erstellung geht AFAIK nicht. Ich hab es schon mit allen möglichen
SQL-Konstrukten versucht, kam aber zu keinem Ergebnis, da der Feldtyp
unbekannt ist. (Wenn man die DB in XML ausgibt, dann steht für ein
Anlagefeld der Definitionsausdruck: od:jetType="complex"
od:jetComplexType="MSysComplexType_Attachment", aber keine Angabe zum
SQL-Äquivalent; also sowas wie od:sqlSType="complex" o.ä.. Ich habe in SQL
die Felddefinition also mit [Feldname] Complex etc. probiert, ACE-SQL kannte
aber keines dieser Ausdrücke. Ich denke, dass es per SQL nicht geht, weil
dazu erst die interne MSys-Tabelle angelegt werden muss, es also in der Tat
ein "Complex"-Vorgang ist. ;-) )
- Anfügeabfragen gehen. Bspe.:
INSERT INTO Tabelle1(NameDS) SELECT "Sascha" ... für den Hauptdatensatz
und
INSERT INTO Tabelle1(Anlagefeld.FileName) SELECT "dummy.dat" FROM Tabelle1
WHERE Tabelle.NameDS = "Sascha" ... für das Anlagefeld.
Soweit, so gut. Möchte man aber analog den Inhalt des Anlagefelds
(Anlagefeld.FileData) übergeben, dann wird das immer mit der Meldung
"Ungültiges Argument" quittiert. Dabei ist es egal, welchen Variablentyp man
übergibt. FileData ist, wenn man es aus einem Recordset2 extrahiert, im
Prinzip ein Variant mit dem Untertyp Byte-Array. Aber weder SELECT
CStr("abdde") noch CVar("abcde") o.ä. wird angenommen. Nimmt man stattdessen
eine benutzerdefinierte Funktion als Anfügewert - was ja wohl auch das
einzig Sinnvolle ist, wenn man eine Datei in ein Anlagefeld kriegen will -,
dann zeigt sich dieses Verhalten: Mit Rückgabewert Variant > "Ungültiges
Argument", mit Rückgabewert Byte() > "Funktion nicht gefunden" (??!). Heißt
also: Geht IMHO nicht! (Ist auch die Frage, wozu man das in SQL machen
sollte, wenn man eh eine UD-Funktion verwenden muss - dann kann man's gleich
komplett per Recordset2 machen.)
- Für Aktualisierungsabfragen gilt das Gleiche, wie für die Anfügeabfragen:
FileName kann aktualisiert werden, FileData nicht.
Die nächste Frage ist, ob man überhaupt per VBA FileData setzen kann. Und
das geht nach meinen Experimenten ebenfalls nicht. Man kann ihm weder einen
Variant noch eine Byte-Array übergeben. Di Fehlermeldungen sind dabei die
gleichen, wie unter SQL. Der Grund liegt warscheinlich darin verborgen, dass
man FileData zwar auslesen kann (> Byte-Array), aber der Vorgang des
Zuweisens eben etwas komplexer ist, weil die Daten von ACE komprimiert
werden. Field2.LoadFromFile analysiert ja erst die Datei und entscheidet
dann anhand der Dateiendung, ob sie überhaupt erlaubt ist und ob sie
komprimiert werden soll. Beim Auslesen geschieht das intransparent im
Hintergrund - ein Auslesen von FileData entpackt automatisch die Daten der
versteckten Systemtabelle. Das Zuweisen lässt den umgekehrten Vorgang aber
offensichtlich nicht zu. Und an die gepackten Daten, wie sie in der
versteckten Systemtabelle drin sind, kommt man, wie gesagt, selbst unter
keinen Umständen ran.
Jedenfalls ist es das, was ich bisher ermitteln konnte. Vielleicht findet ja
aber noch jemand einen raffinierten Weg, an die Anlagesystemtabellen
ranzukommen...
Gruß, Sascha
Peter Doering
Sascha Trowitzsch wrote:
>
> [...] Der Witz ist ja, dass ein
> Anlagefeld selbst eine Art eingebundene Tabelle ist, die mehrere Datensätze
> enthalten kann. An diese internen Tabellen kommt man IMHO von außen nicht
> ran. [...] - Erstellung geht AFAIK nicht.
Kann gerade nicht im Detail darauf eingehen, das meiste davon geht, manches
muss allerdings gesplittet werden. Ich werde am Wochenende ein paar
Beispiele posten.
Peter Doering
Sascha Trowitzsch wrote:
> "Manuela Kulpa" schrieb...
>> Hallo Peter,
>>
>> es tut mir leid, wenn ich mich mit meiner letzten Äußerung wohl ein
>> wenig missverständlich ausgedrückt habe. Es geht mir nicht darum,
>> VBA-mäßig auf Anlagefelder zuzugreifen bzw. zu bearbeiten. Dies war nur
>> eine kleine Bemerkung am Rande. Der Sinn und Zweck von Aktionsabfragen
>> ist ja, auf einen Schlag Daten zu verändern, ohne umständlichen Code zu
>> schreiben.
>
> Ich möchte das nochmal aufgreifen.
> Zunächst ist mir auch nicht klar, wo genau du mit Aktionsabfragen
> Anlagefelder ändern öder hinzufügen willst. Der Witz ist ja, dass ein
> Anlagefeld selbst eine Art eingebundene Tabelle ist, die mehrere Datensätze
> enthalten kann. An diese internen Tabellen kommt man IMHO von außen nicht
> ran. In MSYSObjects sind diese Tabellen zwar unter länglichen Namen, die von
> GUIDs abgeleitet zu sein scheinen, aufgeführt, aber über die
> TableDefs-Auflistung lassen Sie sich nicht ansprechen - "Unbekannt".
Dazu hatte Acki vor einiger Zeit was gepostet:
SELECT
MSysObjects.Name AS Tabelle,
MSysComplexColumns.ColumnName AS Feld,
MSysObjects_1.Name AS FlatTableName
FROM
(MSysObjects INNER JOIN MSysComplexColumns
ON MSysObjects.Id = MSysComplexColumns.ConceptualTableID)
INNER JOIN
MSysObjects AS MSysObjects_1
ON MSysComplexColumns.FlatTableID = MSysObjects_1.Id;
bringt dir Tabellennamen, Feldnamen und den Namen der Tabelle, in der die
MVF-Relationen gespeichert werden.
> Dann ist auch die Frage, welche Art von Aktionsabfrage du genau ausführen
> möchtest. Es ist ein Unterschied, ob du eine Anfüge-, Aktualisierungs- oder
> Erstellungsabfrage ausführen willst:
Genau.
> - Erstellungsabfragen ...
... hab ich vorerst ausgeklammert, weil ich selbst noch nichts damit
gemacht habe. Sollten sich aus obigem Konstrukt ableiten lassen koennen.
> - Anfuegeabfragen:
Das sind, wie du schon erkannt hast, in Zukunft 2 Abfragen. Erst die
Master-DS, dann MVF bzw. Attachments. Ich hab als Beispiel eine Tabelle
Contacts mit den Feldern ...
- ID
- ContactName
- MVF (als Value-Feld, ohne weiteren Link)
- Att (Attachments)
... angelegt. Der Inhalt soll nach NewContacts kopiert werden, die vom
Aufbau her identisch ist.
Schritt 1: Alle Felder excl. MVF
INSERT INTO NewContacts ( ID, ContactName )
SELECT ID, ContactName
FROM Contacts;
Schritt 2a: Das MVF als einziges Feld kopieren
INSERT INTO NewContacts ( MVF.Value )
SELECT MVF.Value
FROM (SELECT MVF.Value, ID
FROM Contacts) AS T1
WHERE NewContacts.ID = T1.ID;
Schritt 2b: Attachments mit FileName und FileData
INSERT INTO NewContacts ( Att.FileName, Att.FileData )
SELECT T1.Att.FileName, T1.Att.FileData
FROM (SELECT Att.FileName, Att.FileData, ID
FROM Contacts) AS T1
WHERE NewContacts.ID = T1.ID;
Schritt 2 muss fuer jedes MVF bzw. Attachments-Feld wiederholt werden.
> Die nächste Frage ist, ob man überhaupt per VBA FileData setzen kann.
Dazu hatten wir bei der AEK ein Beispiel gezeigt, siehe www.donkarl.com,
AEK, Downloads, AEK 9, Neuheiten in A07.
> Und das geht nach meinen Experimenten ebenfalls nicht. Man kann ihm weder
> einen Variant noch eine Byte-Array übergeben.
Du uebergibst den Dateinamen.
> Di Fehlermeldungen sind dabei die
> gleichen, wie unter SQL. Der Grund liegt warscheinlich darin verborgen, dass
> man FileData zwar auslesen kann (> Byte-Array), aber der Vorgang des
> Zuweisens eben etwas komplexer ist, weil die Daten von ACE komprimiert
> werden. Field2.LoadFromFile analysiert ja erst die Datei und entscheidet
> dann anhand der Dateiendung, ob sie überhaupt erlaubt ist und ob sie
> komprimiert werden soll.
Verstehe nicht, was du meinst. Ich hab spasshalber eine Binaerdatei als
Anhang reingehaengt, wurde klaglos uebertragen. Was anderes ist, wenn die
Anlagen im Formular angezeigt werden sollen.
> Beim Auslesen geschieht das intransparent im Hintergrund - ein Auslesen
> von FileData entpackt automatisch die Daten der versteckten
> Systemtabelle. Das Zuweisen lässt den umgekehrten Vorgang aber
> offensichtlich nicht zu. Und an die gepackten Daten, wie sie in der
> versteckten Systemtabelle drin sind, kommt man, wie gesagt, selbst
> unter keinen Umständen ran. Jedenfalls ist es das, was ich bisher
> ermitteln konnte. Vielleicht findet ja aber noch jemand einen
> raffinierten Weg, an die Anlagesystemtabellen ranzukommen...
Nein, naeher als an den Namen kommst du mit Bordmitteln zumindest nicht
ran.
Sascha Trowitzsch
dass du dir nochmal die Zeit genommen hast.
"Peter Doering" <nos...@doering.org> schrieb im Newsbeitrag
news:578iigF...@mid.individual.net...
Yo, Soweit war ich auch schon.
Dabei kommt dann beispielsweise als FlatTableName sowas raus wie:
f_6CAA338CD75140DD8581ED21EF20C88A_AnlageObjekt
Wenn man dann versucht:
SELECT * FROM [f_6CAA338CD75140DD8581ED21EF20C88A_AnlageObjekt]
dann gibt's die Meldung: "Access findet die Abfrage oder Eingangstabelle "
nicht."
Es gibt keinen Zugriff auf diese Systemtabellen. Vielleicht müsste man in
MSysObjects deren Flags verändern? (Die enthalten für diese Tabellen Bits,
die sonst nie auftauchen...)
Das ist interessant. Ich hatte das Kopieren von einer bestehenden in eine
andere Tabelle noch nicht gemacht.
Ich hatte versucht, FileData nicht aus einem bestehenden anderen FileData zu
übertragen, sondern den Wert direkt zu setzen; also etwa:
INSERT INTO NewContacts ( Att.FileName, Att.FileData ) VALUES ("test",
"abcde") WHERE NewContacts.ID =1
Und das "abcde" will Access nicht; auch nicht in diesen Schreibweisen:
- INSERT INTO NewContacts ( Att.FileName, Att.FileData ) VALUES ("test",
CVAR("abcde")) WHERE NewContacts.ID =1
- INSERT INTO NewContacts ( Att.FileName, Att.FileData ) VALUES ("test",
fuAttch() ) WHERE NewContacts.ID =1
(wobei fuAttch eine UDF mir Rückgabewert Variant oder Bytearray ist)
Und deshalb:
>> Die nächste Frage ist, ob man überhaupt per VBA FileData setzen kann.
>
> Dazu hatten wir bei der AEK ein Beispiel gezeigt, siehe www.donkarl.com,
> AEK, Downloads, AEK 9, Neuheiten in A07.
>
>> Und das geht nach meinen Experimenten ebenfalls nicht. Man kann ihm weder
>> einen Variant noch eine Byte-Array übergeben.
>
> Du uebergibst den Dateinamen.
Naja, das ist mir klar, wie ich's als Datei per Field2 und LoadFromFile
laden kann.
Auf VBA kam ich ja nur, weil ich dachte, dass da das möglich sein könnte,
was oben (Att.FileData = CVar("abcde" ) in SQL nicht geht.
Also sieht der Versuch so aus:
Dim fld2 As Field2
Set fld2 = Currentdb.OpenRecordset("SELECT [Att] FROM
[NewContacts]",dbopendynaset).Fields(0).Value.Fields("FileData")
Debug.Print TypeName(fld2.Value), fld2.Value
'... = Byte() , ...Byte-String...
... Und fld2.Value (Typ Byte-Array) kann man eben anschließend im Edit-Mode
keinen Wert zuweisen, nur auslesen. Deshalb:
>> Die Fehlermeldungen sind dabei die
>> gleichen, wie unter SQL. Der Grund liegt warscheinlich darin verborgen,
>> dass
>> man FileData zwar auslesen kann (> Byte-Array), aber der Vorgang des
>> Zuweisens eben etwas komplexer ist, weil die Daten von ACE komprimiert
>> werden. Field2.LoadFromFile analysiert ja erst die Datei und entscheidet
>> dann anhand der Dateiendung, ob sie überhaupt erlaubt ist und ob sie
>> komprimiert werden soll.
>
> Verstehe nicht, was du meinst.
Hoffe, du hast es anhand meines VBA-Beispiels verstanden.
Wahrscheinlich missbrauche ich damit Manuelas Thread, aber dahinter steht,
dass ich per VBA Attachments auslesen und setzen möchte, OHNE den Umweg als
Datei, sondern mittels Byte-Arrays.
Auslesen geht wie beschrieben, wobei ich zur allgemeinen Info noch
preisgebe, was ich über den Aufbau von FileData herausbekommen habe:
Den eigentlichen Binärdaten ist ein Header vorangestellt, der Folgendes
Format hat:
'mossSOFT: HEADER-Aufbau Attachment.Field2!FileData
'---------------------------------
'Offset Datentyp Bedeutung
'---------------------------------
'0 Long Länge Header (n)
'4 Long ?? ; anscheinend immer 1; evtl. Versionsnummer
'8 Long Länge Dateiendung inkl. Punkt (Bsp.: .txt = 4;
.accde=6)
'12ff. String Dateiendung DBCS; nullterminiert (=2x0)
'> n Byte-Array Binärdaten
Damit:
Public Type TFileData
LenHeader As Long
Descriptor As Long
LenExtension As Long
strExtension As String
Data() As Byte
End Type
Anhand des Headers kann man dann ermitteln, an welchem Offset die
eigentlichen Daten beginnen, diese in ein Byte-Array laden und
weiterverwenden - etwa, um aus PNG-Daten per GDI+ ein Picture-Objekt in
memory zu erzeugen.
Nur den umgekehrten Vorgang, also das Erzeugen oder Modifizieren eines
FileData mit einem Byte-Array, den bekomme ich bisher nicht hin, weil Field2
keinerlei VB-Datentyp akzeptiert - auch kein Byte-Array. Und das ist
irritierend, weil das Setzen von FileData mit der Anfügeabfrage ja geht.
Werde aber mal weiterforschen.
Gruß, Sascha
Sascha Trowitzsch
> Werde aber mal weiterforschen.
Ich weiß auch nicht, wieso das vorher nicht ging... :-(
Mit weiteren Tests funktioniert plötzlich die Zuweisung eines Byte-Arrays.
Im Folgenden ein Beispielcode, mit dem man - alternativ zu
Field2.LoadFromFile - eine Datei in ein Attachment-Feld speichern kann. Sie
hat den Vorteil, dass die Blockade nicht erlaubter Dateiendungen entfällt.
;-)
Voraussetzung: Eine Tabelle sTable mit einem AnlageFeld sAttchField (...und
keinen weiteren Pflichtfeldern)
'******************************************************
Private Type TFileData
LenHeader As Long
Descriptor As Long
LenExtension As Long
strExtension As String
Data() As Byte
End Type
Private Declare Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory" ( _
ByRef Destination As Any, _
ByRef Source As Any, ByVal Length As Long)
'Datei sFile in Tabelle sTable mit Anlagefeld sAttchField speichern
Sub TestFileData(sFile As String, sTable As String, sAttchField As String)
Dim FLH As TFileData
Dim rsMaster As Recordset2
Dim rsDetail As Recordset2
Dim bin() As Byte
Dim F As Integer
Dim n As Long
With FLH
.strExtension = Mid(sFile, InStrRev(sFile, ".") + 1) & Chr$(0)
.Descriptor = 1
.LenExtension = Len(.strExtension)
.LenHeader = 12 + LenB(.strExtension)
End With
F = FreeFile
Open sFile For Binary Access Read As F
ReDim FLH.Data(LOF(F))
Get #F, , FLH.Data
Close F
n = UBound(FLH.Data)
ReDim bin(FLH.LenHeader + n)
CopyMemory bin(0), FLH, FLH.LenHeader
CopyMemory bin(LenB(FLH)), FLH.Data(0), n
Set rsMaster = CurrentDb.OpenRecordset("SELECT * FROM " & sTable,
dbOpenDynaset)
rsMaster.AddNew
Set rsDetail = rsMaster.Fields(sAttchField).Value
rsDetail.AddNew
rsDetail!FileData.Value = bin
rsDetail!Filename.Value = Mid(sFile, InStrRev(sFile, "\") + 1)
On Error Resume Next
rsDetail.Update
rsDetail.Close
Set rsDetail = Nothing
rsMaster.Update
rsMaster.Close
Set rsMaster = Nothing
Erase FLH.Data
Erase bin
End Sub
'******************************************************
Gruß, Sascha