Ungebundene Felder füllen

Okay, das ist natürlich ernüchternd. Aber dann gib mir doch noch einen Tipp. Wenn ich das ganze mit einer gebundenen Form mache, wie kann ich dann am besten Felder schreibschützen, bzw. den Schreibschutz lösen? Wenn ich das hinbekomme, wäre ich fürs erste auch mit dieser Variante zufrieden…
Grüße,
Sebastian

Oder noch was anderes:
Das ursprüngliche Problem besteht noch: ich lade Daten ein, die zum Teil schreibgschützt sind. Die Form ist daraufhin nicht „updatable“.
Wie löse ich das?
Danke!

Um das ganze noch abzurunden:
Es handelt sich im Wesentlichen um 3 Tabellen, die in der Form dargestellt werden. Eine ist der Master, die zweite beinhaltet eindeutige Zusatzinformationen zu den Einträgen im Master(immer 1 Set zu 1 Eintrag). Die dritte enthält manchmal Informationen zu den Mastereinträgen. Zur Zeit ist das mit einer (Master-)Form und einem Unterformular, das die Daten der anderen zwei Tabellen enthält, gelöst. Das Problem war, das wir gerne nach den Daten der zweiten Tabelle filtern wollten. Dazu „hoben“ wir diese Daten in die Masterform und liessen nur noch die Daten der dritten Tabelle in der Subform. Leider läßt sich das Formular nun nicht mehr updaten, vermutlich weil die 2.Tabelle schreibgeschützte Daten enthält (das soll auch so sein). Als Alternative kam nun eine ungebundene Form auf den Tisch, denn dort sollte das alles „gar kein Problem“ sein…

wie kann ich dann am besten Felder schreibschützen, bzw. den Schreibschutz lösen?

Bei Feldern hat man die Möglichkeit der Einstellung: Rechtsklick -> Eigenschaften -> Reiter [Daten]

Es gibt zwei Einstellungen die man gemeinsam betrachten sollte:
Aktiviert: Ja/Nein
Gesperrt: Ja/Nein

Auch per VBA lassen sich diese Felder sperren und/oder freigeben.

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)

Wie löse ich das?

in dem du die Datenbasis (Tabellen) richtig miteinander verknüpfst

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)

Gut, das hier ist der SQL-Code (sorry, keine Ahnung, wie man das ordentlich formatiert hier):

SELECT CASE WHEN NULLIF
((SELECT COUNT(Auftrag)
FROM [Fehlermeldung].[dbo].[Fehlermeldungen] f INNER JOIN
[dbo].[holdLOT] hl ON f.Auftrag = LEFT(hl.batchLot, 6)
GROUP BY Auftrag
HAVING f.Auftrag = LEFT(holdlot.batchLot, 6)), 0) > 0 THEN 1 ELSE 0 END AS fehlermeldung,
(SELECT COUNT(f.Auftrag) AS Expr1
FROM Fehlermeldung.dbo.Fehlermeldungen AS f INNER JOIN
dbo.holdLOT AS hl ON f.Auftrag = LEFT(hl.batchLot, 6)
GROUP BY f.Auftrag
HAVING (f.Auftrag = holdlot.batchLot)) AS anzahlFehlermeldungen, dbo.camic.process, dbo.batrel.Info, dbo.holdLOT.*, dbo.batrel.Status,
dbo.camic.[Bus#Line L], dbo.camic.Anz#, dbo.camic.TYP_BEZ AS TYPE, dbo.camic.NK, dbo.camic.MB, dbo.camic.Automotive, dbo.camic.Mav,
dbo.camic.TestCenter, dbo.camic.diff#group, dbo.camic.Stufe
FROM dbo.holdLOT INNER JOIN
dbo.camic ON dbo.holdLOT.batchLot = dbo.camic.AUF LEFT OUTER JOIN
dbo.batrel ON dbo.holdLOT.batchLot = dbo.batrel.Batch


Dazu folgendes: holdLot ist der Master, Camic und Batrel werden dem Master auf dem Formular zugeordnet. batchlot ist der Schlüssel. Das Ganze mit Fehlermeldung dient dazu die Anzahl von Fehlermeldungen zu einer Produktcharge sehen zu können.
Was muss ich also hier konkret ändern, damit die Verknüpfung ein Updaten der Form erlaubt?

so langsam wird die Sache klarer :smile:

Leider läßt sich das Formular nun nicht mehr updaten, vermutlich weil die 2.Tabelle schreibgeschützte Daten enthält (das soll auch so

sein).

vermutlich? Ich vermute, diese ganze Tabelle ist schreibgeschützt!?

Am besten du schreibst mal, um welche Art Tabellen es sich handelt.
Welche Felder zum Filter genutzt werden sollen und wie du den Filter erstellst (Code) usw.

Belasse die Tabellen dort, wo sie waren. Man kann auch mit der Dlookup Funktion die Daten aus einer anderen Tabelle holen.

Als Alternative kam nun eine ungebundene Form auf den
Tisch, denn dort sollte das alles „gar kein Problem“ sein…

alles ist relativ, wenn du unnötigen Aufwand betreiben willst, Programmiererfahrung hast etc. pp. könnte man es so machen.

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)

Gut, das hier ist der SQL-Code (sorry, keine Ahnung, wie man
das ordentlich formatiert hier)

lese dazu die FAQ:30 und schau mal unterhalb dieses weißen Eingabefeldes, dort werden die HTML-Tags, mit der entsprechenden Hilfe aufgelistet

Was muss ich also hier konkret ändern, damit die Verknüpfung
ein Updaten der Form erlaubt?

verwende nur die Mastertabelle für das Hauptformular, für das UFO (Unterformular) verwendest du dann die beiden anderen Tabellen.

Da du hier im SQL-Code Berechnungen durchführst, ist die Aktualisierung nicht möglich!

Da es sich um eine Auswertung handelt, wäre ein Bericht als Ergebnisübersicht sinnvoller.

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)

lese dazu die FAQ:30 und schau mal unterhalb dieses weißen
Eingabefeldes, dort werden die HTML-Tags, mit der
entsprechenden Hilfe aufgelistet

Danke, werde ich bei Gelegenheit tun.

verwende nur die Mastertabelle für das Hauptformular, für das
UFO (Unterformular) verwendest du dann die beiden anderen
Tabellen.

Ich möchte aber nach den Daten filtern können. Das kann ich nicht so ohne weiteres, wenn ich einen Teil in das UFO tue!

Da du hier im SQL-Code Berechnungen durchführst, ist die
Aktualisierung nicht möglich!

Wie kann ich die Berechnung woanders machen, damit das geht?

Da es sich um eine Auswertung handelt, wäre ein Bericht als
Ergebnisübersicht sinnvoller.

Kann ich mit dem Bericht auch die Daten editieren usw.? Gibt es beim Bericht Einschränkungen gegenüber der Form?

Ich möchte aber nach den Daten filtern können. Das kann ich
nicht so ohne weiteres, wenn ich einen Teil in das UFO tue!

der SQL-Code hat keinen WHERE Anteil, der eine Filterung darstellten könnte. Auch verweist keinen der Variablen auf ein Formularfeld, das als Filterkriterium dienen könnte.

Nochmal gefragt: wie soll die Filterung erfolgen?

Da du hier im SQL-Code Berechnungen durchführst, ist die
Aktualisierung nicht möglich!

Wie kann ich die Berechnung woanders machen, damit das geht?

in VBA, schau dir die Funktionen DCount, Dsum etc. an.

Kann ich mit dem Bericht auch die Daten editieren usw.?

ein Bericht ist ein „Ausdruck“ auf dem Bildschirm und/oder auf dem Drucker.
Es gilt generell: editieren im Formular, auswerten im Bericht!

Gibt es beim Bericht Einschränkungen gegenüber der Form?

erstelle einen Bericht und schau es dir an.

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)

Nochmal gefragt: wie soll die Filterung erfolgen?

Gefiltert werden soll mit den üblichen „rechte Maustaste“ Filterfuntionen in dem Formular. Und zwar auch nach Daten aus „CAMIC“, weswegen wir sie auf das Hauptformular gehoben haben…
wir wollen z.B. alle Datensätze eines Produktionstypen haben. Welchen Typ eine Charge hat, steht in CAMIC.

in VBA, schau dir die Funktionen DCount, Dsum etc. an.

Okay, danke, danach werde ich gucken. Kommt das dann in Form.Open oder wohin?

Es gilt generell: editieren im Formular, auswerten im Bericht!

Ich MUSS editieren können. Also brauche ich ein Formular.

Grüße,
Sebastian

Gefiltert werden soll mit den üblichen „rechte Maustaste“
Filterfuntionen in dem Formular.

eigentlich macht man das nicht so. Im Formularkopf legt man z.B. entsprechende (Such)Felder an, aus deren Inhalt man dann einen Filter baut.

Und zwar auch nach Daten aus
„CAMIC“, weswegen wir sie auf das Hauptformular gehoben
haben…

wie viele Felder aus der Tabelle wären es denn die benötigt werden?

wir wollen z.B. alle Datensätze eines Produktionstypen haben.
Welchen Typ eine Charge hat, steht in CAMIC.

also im Formularkopf ein Kombifeld dafür einrichten. Über die ID ist dann ein Filter zu erstellen.

in VBA, schau dir die Funktionen DCount, Dsum etc. an.

Okay, danke, danach werde ich gucken. Kommt das dann in
Form.Open oder wohin?

in die Abfrage, die dein Hauptformular speist. (Datenherkunft)

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)

Im Formularkopf legt man z.B. entsprechende (Such)Felder an,
aus deren Inhalt man dann einen Filter baut.
also im Formularkopf ein Kombifeld dafür einrichten. Über die
ID ist dann ein Filter zu erstellen.
wie viele Felder aus der Tabelle wären es denn die benötigt
werden?

Es wären 9 Felder… die Idee mit den Kombifeldern hatten wir auch schon, schien uns aber keine elegante Lösung… die Methode mit der rechten Maustaste ist einfach viel flexibler und klappt für Feldeer, die im Hauptformular stehen super. Wenn ich jetzt die Rechnung mit VBA in die Abfrage setze, müßte das Updaten doch funktionieren und das Filtern auch, oder?

in die Abfrage, die dein Hauptformular speist. (Datenherkunft)

Kannst Du mir da ein Beispiel geben, wie das aussehen würde?

Danke!

Es gibt zwei Einstellungen die man gemeinsam betrachten
sollte:
Aktiviert: Ja/Nein
Gesperrt: Ja/Nein

Auch per VBA lassen sich diese Felder sperren und/oder
freigeben.

Kannst Du mir dafür ein Beispiel geben? Danke!

Es wären 9 Felder… die Idee mit den Kombifeldern hatten wir
auch schon, schien uns aber keine elegante Lösung…

kommt drauf an, ich muss so oder so bis zu 9 Felder ausfüllen.

die
Methode mit der rechten Maustaste ist einfach viel flexibler
und klappt für Feldeer, die im Hauptformular stehen super.

ok

Wenn ich jetzt die Rechnung mit VBA in die Abfrage setze,

welche Rechnung?

müßte das Updaten doch funktionieren und das Filtern auch,
oder?

wenn du alles richtig machst, ja

in die Abfrage, die dein Hauptformular speist. (Datenherkunft)

Kannst Du mir da ein Beispiel geben, wie das aussehen würde?

welches Beispiel benötigst du für eine einfache Abfrage?
wie heißt die Basistabelle?
welche Tabellenfelder sollen im Formular angezeigt werden?
welche Felder sollen berechnet werden?
welche Felder sollen gesperrt und welche editierbar sein?
welche 9 Felder sollen für einen Filter verwendet werden?

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)

Beispiele in VBA:

Me.Telefon.Enabled = False
Me.Telefon.Locked = True

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)

Hallo,

jetzt muss ich das ganze nochmal etwas strukturieren:
Ich habe nun folgenden SQL-Code.
SELECT dbo.holdLOT.*, dbo.camic.process, dbo.batrel.Info, dbo.batrel.Status, dbo.camic.[Bus#Line L], dbo.camic.Anz#, dbo.camic.TYP_BEZ AS TYPE, dbo.camic.NK, dbo.camic.MB, dbo.camic.Automotive, dbo.camic.Mav, dbo.camic.TestCenter, dbo.camic.diff#group, dbo.camic.Stufe
FROM dbo.holdLOT INNER JOIN
dbo.camic ON dbo.holdLOT.batchLot = dbo.camic.AUF LEFT OUTER JOIN
dbo.batrel ON dbo.holdLOT.batchLot = dbo.batrel.Batch

Also keine Berechnungen mehr. Die Berechnung, die vorher (Re^4) am Anfang des Codes stand, prüfte, ob und wie häufig „batchlot“ in der Tabelle fehlermeldungen vorkommt. Das wollte ich nun im Code machen (und ein Feld mit der Anzahl füllen). Leider ist auch mit obigem gekürzten SQL-Code die Form immer noch „not updatable“.
Wieso ist das noch so?
und
Wie würde eine Berechnung a la „wie oft findest du holdlot.batchlot in fehlermeldungen“ in VBA aussehen? Brauche ich dafür wieder einen Inner Join und ähnliches?

welches Beispiel benötigst du für eine einfache Abfrage?
wie heißt die Basistabelle?

die basistabelle heisst holdlot
die anderen tabellen heissen camic und batrel, sowie fehlermeldungen (hier soll aber nur die anzahl herausgezogen werden)

welche Tabellenfelder sollen im Formular angezeigt werden?
welche Felder sollen berechnet werden?
welche Felder sollen gesperrt und welche editierbar sein?

z.B. batchlot (gesperrt), remarks(editierbar), futurehold(editierbar) und etwas 15 weitere (editierbar) aus holdlot;
Type(gesperrt), process(gesperrt) und BL(gesperrt) aus camic;
info(gesperrt) aus batrel;
und wie gesagt anzahlfehlermeldungen aus fehlermeldungen (berechnen)

Vielen Dank für Deine Mühe,
Sebastian

Hallo,

jetzt muss ich das ganze nochmal etwas strukturieren:
Ich habe nun folgenden SQL-Code.
SELECT dbo.holdLOT.*, dbo.camic.process, dbo.batrel.Info,
dbo.batrel.Status, dbo.camic.[Bus#Line L], dbo.camic.Anz#,
dbo.camic.TYP_BEZ AS TYPE ,

TYPE ist ein reserviertes Wort in Access und sollte für eigene Bezeichnungen nicht verwendet werden!

dbo.camic.NK, dbo.camic.MB,

dbo.camic.Automotive, dbo.camic.Mav, dbo.camic.TestCenter,
dbo.camic.diff#group, dbo.camic.Stufe
FROM dbo.holdLOT INNER JOIN
dbo.camic ON dbo.holdLOT.batchLot =
dbo.camic.AUF LEFT OUTER JOIN
dbo.batrel ON dbo.holdLOT.batchLot =
dbo.batrel.Batch

Also keine Berechnungen mehr. Die Berechnung, die vorher
(Re^4) am Anfang des Codes stand, prüfte, ob und wie häufig
„batchlot“ in der Tabelle fehlermeldungen vorkommt. Das wollte
ich nun im Code machen (und ein Feld mit der Anzahl füllen).

ok

Leider ist auch mit obigem gekürzten SQL-Code die Form immer
noch „not updatable“.
Wieso ist das noch so?

= weil immer noch Joins zu BATREL und CAMIC existieren
= wie schon geschrieben, ist eine dieser Tabellen schreibgeschützt!?
du solltest also erstmal diese Frage klären!

und
Wie würde eine Berechnung a la „wie oft findest du
holdlot.batchlot in fehlermeldungen“ in VBA aussehen? Brauche
ich dafür wieder einen Inner Join und ähnliches?

nein, - wie schon geschrieben - reicht dafür DCOUNT aus

welches Beispiel benötigst du für eine einfache Abfrage?
wie heißt die Basistabelle?

die basistabelle heisst holdlot
die anderen tabellen heissen camic und batrel, sowie
fehlermeldungen (hier soll aber nur die anzahl herausgezogen
werden)

welche Tabellenfelder sollen im Formular angezeigt werden?
welche Felder sollen berechnet werden?
welche Felder sollen gesperrt und welche editierbar sein?

z.B. batchlot (gesperrt), remarks(editierbar),
futurehold(editierbar) und etwas 15 weitere (editierbar) aus
holdlot;
Type(gesperrt), process(gesperrt) und BL(gesperrt) aus camic;

das Sperren kannst du ja - wie beschrieben - für die Felder einstellen.

info(gesperrt) aus batrel;

nur für die „Info“ brauchst du keinen Join, sondern holst dir die Info über die Funktion Dlookup.

und wie gesagt anzahlfehlermeldungen aus fehlermeldungen
(berechnen)

wie schon geschrieben, machst du das mit der Funktion DCount

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)

TYPE ist ein reserviertes Wort in Access
und sollte für eigene Bezeichnungen nicht verwendet werden!

Okay, kann ich umbenennen, kein Problem.

Leider ist auch mit obigem gekürzten SQL-Code die Form immer
noch „not updatable“.
Wieso ist das noch so?

= weil immer noch Joins zu BATREL und CAMIC existieren
= wie schon geschrieben, ist eine dieser Tabellen
schreibgeschützt!?
du solltest also erstmal diese Frage klären!

Tatsächlich ist die Tabelle batrel schreibgeschützt! Wenn ich die aus der SQL-Abfrage lösche, kann ich sogar die Fehlermeldungen-Rechnung wieder reinnehmen UND filtern, wie es mir gefällt! Prima!

das Sperren kannst du ja - wie beschrieben - für die Felder
einstellen.

Das muss ich noch probieren. Mal schauen.

info(gesperrt) aus batrel;

nur für die „Info“ brauchst du keinen Join, sondern holst dir
die Info über die Funktion Dlookup.

und wie gesagt anzahlfehlermeldungen aus fehlermeldungen
(berechnen)

Das habe ich versucht:
dlookup ("[info]",„batrel“,"[batch] = " & Me![fldbatchlot])
Wo ist der Fehler?
dlookup ("[info]",„batrel“) funktioniert, d.h. zeigt den ersten Eintrag der Tabelle. In der Tabelle Batrel heisst der „Schlüssel“ batch, in der Tabelle holdLot heisst er batchlot (und in der Form frmholdlot heisst er fldbatchlot)).

Ich komme der Lösung jetzt endlich nahe!

Grüße,
Sebastian

Das habe ich versucht:
dlookup ("[info]",„batrel“,"[batch] = " & Me![fldbatchlot])
Wo ist der Fehler?

ich vermute mal BATCH wird auch als reserviertes Wort behandelt.
und/oder mal ein paar Klammern weniger verwenden:

dlookup („info“,„batrel“,"[batch] = " & Me.fldbatchlot)

und/oder eine Kontrolle einbauen:

if isnull(Me.fldbatchlot) then
 msgbox "Fehler"
else
 me.Feldbezeichnung = dlookup ("info","batrel","[batch] = " & Me.fldbatchlot)
end if

das gilt natürlich nur, wenn Batch und fldbatchlot eine Zahl ist!

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)