Erstellungsabfrage mit ID und Autowert versehen

[MrB]

Nächste Frage, die scheinbar schon seit langem im Netz kursiert, aber nie wirklich beantwortet wird, oder ich finde die richtige Antwort einfach nicht.

Ich möchte innerhalb einer Datenbank eine Erstellungsabfrage laufen lassen, die ein Projekt auf eine bestimmmte Gruppe oder Anzahl der vorhandenen Mögichkeiten einschränkt(zB nur die Lehrwerkstatt 1. 3. 5). Diese Abfrage soll dann über eine Erstellungsabfrage eine neue Tabelle anlegen.
Soweit so gut, bekomme ich hin.
Leider fehlt aber bei der Tabelle der Primary Key und ich habe nur gefunden wie man eine Nummerierung erzeugen kann, diese aber kein Autowert ist.
Gibt es hier eine einfache Lösung?
Falls nicht würde ich über eine Verbindungstabelle gehen und über eine Anfügeabfrage die Projekte einfach anhängen.
Mir wäre die erste Lösung mit den Einzeltabellen aber lieber, um dann die Bearbeitung einzuschränken, damit nach Beendigung keine Änderungen mehr gemacht werden können.
Ich hoffe meine Erklärung ergibt Sinn und ist Verständlich
Cord

[MzKlMu]

Hallo,
erstelle erste die Tabelle mit dem Autowert und nimm dann eine Anfügeabfrage und füge dann die DS an.

Aber wozu soll das gut sein ?
Du hast doch die Daten in einer Abfrage vorliegen, wozu brauchst Du da eine Tabelle ? Die Daten wären dann doch redundant. Und in einer Datenbank soll man ja Redundanz vermeiden.

Und außerdem:

damit nach Beendigung keine Änderungen mehr gemacht werden können.

Mit einer Abfrage ist es einfacher Änderungen nicht zuzulassen.

[PhilS]

Mir wäre die erste Lösung mit den Einzeltabellen aber lieber, um dann die Bearbeitung einzuschränken, damit nach Beendigung keine Änderungen mehr gemacht werden können.

Ich hoffe meine Erklärung ergibt Sinn und ist Verständlich

Sinn? Nicht so ganz.
Wenn die Bearbeitbarkeit durch das Kopieren in die Einzeltabellen eingeschränkt werden soll, wozu brauchst du dann einen AutoWert?

Die Idee mit den Einzeltabellen erscheint mir insgesamt grundlegend fragwürdig. Sowas ist üblicherweise nur sinnvoll für Temporärtabellen im Rahmen eines mehrstufigen Prozesses, z.B. eines komplexen Datenexports. In deiner Beschreibung lese ich nichts, was mir die Einzeltabellen als sinnvolle Lösung erscheinen lassen könnte.

[MrB]

Du hast doch die Daten in einer Abfrage vorliegen, wozu brauchst Du da eine Tabelle ? Die Daten wären dann doch redundant. Und in einer Datenbank soll man ja Redundanz vermeiden.

Moin Klaus,
Die Daten werden nicht direkt Redundant, sondern nur als Schlüssel einem Projekt zugeteilt, zB Projekt1, Projekt2 usw.
Das will ich dafür nutzen, damit ich nicht immer wieder die Abfrage neu mit Filtern füllen muss die ich mir merken muss.

erstelle erste die Tabelle mit dem Autowert und nimm dann eine Anfügeabfrage und füge dann die DS an.

Ok das entspricht dem was ich mir ausgedacht habe, als Ausweichmöglichkeit
Danke

Wenn die Bearbeitbarkeit durch das Kopieren in die Einzeltabellen eingeschränkt werden soll, wozu brauchst du dann einen AutoWert?

Weil ich die Tabellen als Ausgangswert nutzen wollte, anstatt die Haupttabelle in der ich immer wieder alles einschränken muss.

Die Idee mit den Einzeltabellen erscheint mir insgesamt grundlegend fragwürdig. Sowas ist üblicherweise nur sinnvoll für Temporärtabellen im Rahmen eines mehrstufigen Prozesses, z.B. eines komplexen Datenexports. In deiner Beschreibung lese ich nichts, was mir die Einzeltabellen als sinnvolle Lösung erscheinen lassen könnte.

Hat sich erledigt ich nehme die Zwischentabelle, arbeiten ja eh nur wir selber damit. Ich hoffe, das ich Fehler vermeiden kann indem ich meine Kollegen sensibilisiere.
Cord

[MzKlMu]

Hallo,
Deine Vorhaben ist Unsinn (entschuldige bitte die drastische Ausdrucksweise, aber ich kann das nicht anders bezeichnen).

Die Daten werden nicht direkt Redundant,

Aber natürlich ist das redundant. Du hast die Daten bereits in Tabellen vorliegen und speicherst sie zusätzlich noch in anderen Tabellen. Das ist redundate Datenhaltung und sonst nichts. Außerdem sind solche zusätzliche Tabellen problematisch, weil Du nie sicher sein kannst, dass die Daten aktuell sind. Wenn Du in den Ursprungstabellen eine Fehler findest und diesen korrigieren musst, musst Du sicher stellen, dass das auch in der erstellten Tabelle korrigiert wird.
Der Autowert in diesen zu erstellenden Tabellen ist auch überflüssig und macht auch keinen Sinn, damit kannst Du nichts anfangen weil es keinen Bezug zu anderen Tabellen gibt.

Weil ich die Tabellen als Ausgangswert nutzen wollte, anstatt die Haupttabelle in der ich immer wieder alles einschränken muss.

Speichere diese Auswahlen als Abfrage und vergib diesen Namen den Du für die zusätzlichen Tabellen verwenden wolltest. Das macht keinen Unterschied zu Tabellen. Abfragen und Tabellen sind da gleichwertig.

Wenn Du die Abfragen mit dem Recordsettyp "Snapshot" speicherst, sind diese automatsich schreibgeschützt und es können keine Änderung an den Daten vorgenommen werden.

Lange Rede kurzer Sinn: Lasse es sein.

[ebs17]

damit ich nicht immer wieder die Abfrage neu mit Filtern füllen muss die ich mir merken muss

Es kann durchaus Sinn machen, häufiger zu verwendende Filter (die nichts anderes als ein String sind) in einer zusätzlichen Tabelle gemeinsam mit einem Namen / einer Beschreibung zu speichern und bei Bedarf zu holen.

[MrB]

Ok, leider musste ich mich für ein paar Tage mit anderen Aufgaben beschäftigen, jetzt also zurück zum Problem, das ich schon als gelöst gesehen habe.

Außerdem sind solche zusätzliche Tabellen problematisch, weil Du nie sicher sein kannst, dass die Daten aktuell sind. Wenn Du in den Ursprungstabellen eine Fehler findest und diesen korrigieren musst, musst Du sicher stellen, dass das auch in der erstellten Tabelle korrigiert wird.

Ok habe ich verstanden, kann natürlich zu Problemen führen, wenn Daten verändert werden.

Speichere diese Auswahlen als Abfrage und vergib diesen Namen den Du für die zusätzlichen Tabellen verwenden wolltest. Das macht keinen Unterschied zu Tabellen. Abfragen und Tabellen sind da gleichwertig.

Ja sind gleichwertig und immer aktuell, egal was ich verändere, aber dann muss ich für jedes Projekt eine neue Abfrage speichern? Ich kenne ja eine Tabellenerstellungsabfrage, aber recordset habe ich mich noch nie mit befasst. Werde ich versuchen mich einzulesen.

Es kann durchaus Sinn machen, häufiger zu verwendende Filter (die nichts anderes als ein String sind) in einer zusätzlichen Tabelle gemeinsam mit einem Namen / einer Beschreibung zu speichern und bei Bedarf zu holen.

Das würde bedeuten eine Abfrage zu erstellen, die allgemeingültig ist und einen Filter einem Projekt zuzuordnen, der dann die Abfrage anpasst?
Der Filter wird dann über ein Formular zusammengesetzt in eine Tabelle übertragen und von dort aus in die Abfrage übergeben? 
Ihr traut mir ja was zu.
Ich stelle nicht in Frage das alles richtig ist und gut was ihr schreibt, aber die Umsetzung macht mir echt Kopfschmerzen.

Mfg Cord

[PhilS]

Das würde bedeuten eine Abfrage zu erstellen, die allgemeingültig ist und einen Filter einem Projekt zuzuordnen, der dann die Abfrage anpasst?

Ja, genau, so in etwa.

Der Filter wird dann über ein Formular zusammengesetzt in eine Tabelle übertragen und von dort aus in die Abfrage übergeben? 
Ihr traut mir ja was zu.
Ich stelle nicht in Frage das alles richtig ist und gut was ihr schreibt, aber die Umsetzung macht mir echt Kopfschmerzen.

Wenn dieser Filter von dir als Admin (oder einen anderen, technisch versierten Benutzer) manuell vorbereitet/zusammengesetzt wird und dann nur als Text in der Tabelle gespeichert wird, ist das nicht besonders schwierig.

Du holst dir dann einfach den Filter für das gewählte Projekt aus der Tabelle, z.B. mit DLookup, und übergibst ihn dann als Where-Condition an die weiteren Detailformulare.

Eine UI (Formular) um diesen Filter mit einer netten Oberfläche im Programm zusammenzubauen, kann schnell recht anspruchsvoll werden. - Abhängig von der Komplexität der Kriterien. - Das würde ich eher zurückstellen oder nur für einfache Basisfälle vorsehen.

[ebs17]

Ihr traut mir ja was zu.

Wenn die unbedarften User sorgenfrei arbeiten sollen, muss der Entwickler etwas vorarbeiten und alle Sorgen und Probleme bestmöglich beseitigt haben. Ein Display, wo man nur 10 Ziffern und eine Starttaste hat, kann jeder bedienen, ohne Extra-Beschreibung.

Wegen des variablen Filterns: Kannst Du Dir vorstellen, dass Du nicht der Allererste bist, der so eine Standardaufgabe vor Augen hat? Zum Thema Suchformular/Filterklassen gibt es unzählige beispiele, von denen man abschreiben kann.

Stelle Dich der (noch übersichtlichen) Herausforderung, oder gib einem anderen die Chance.

[MzKlMu]

Hallo,
bevor hier über Abfragen etc. nachgedacht wird, sollte erst mal die Tabellenstruktur klar sein.
Die Gestaltung der Abfragen hängt ja sehr stark von der Tabellenstruktur (dem Datenmodell) ab.

Daher solltest Du bevor Du weiter machst erst mal das aktuelle Beziehungsbild hier zeigen.

[MrB]

Eine UI (Formular) um diesen Filter mit einer netten Oberfläche i

Nett muss die nicht sein nur funktionell, bleibt alles nur bei uns in der Firma, aber auch das stellt mich vor Herausforderungen. Ich muss mich immer wieder Stück für Stück einlesen, ausprobieren und fehlersuchen.

DlookUp habe ich zB noch nie genutzt.

Wegen des variablen Filterns: Kannst Du Dir vorstellen, dass Du nicht der Allererste bist, der so eine Standardaufgabe vor Augen hat? Zum Thema Suchformular/Filterklassen gibt es unzählige beispiele, von denen man abschreiben kann.

Das stimmt, habe ich ja mit Mehrfachauswahl bei einem Formular hinbekommen und versuche das jetzt in ein neues zu Übertragen und stehe wieder vor Fehlern, die ich nicht einordnen kann.

Sie dürfen in diesem Board keine Dateianhänge sehen.

Code [Auswählen] Erweitern

SELECT tblBuilding.GEB
,tblTeile.G_ITEM_German
,tblStuecklistenName.Name_Engl
,tblTeile.SG_ITEM_German
,tblTeile.HK_SG_SP
,tblTeile.ITEM_Details
,tblTeile.REM
,tblTeile.FK_MG_ID
,tblStueckliste.QTY
,[AnzahlStueckliste] * [QTY] AS menge
,[HK_SG_SP] * ([AnzahlStueckliste] * [QTY]) AS Zwischensumme
,tblBuilding.NameBuilding
,tblBuildingStuecklisten.AnzahlStueckliste
,tblStuecklistenName.Name_short
FROM tblBuilding
INNER JOIN (
(
tblTeile INNER JOIN (
tblStuecklistenName INNER JOIN tblStueckliste ON tblStuecklistenName.[PK_StuecklistenName_ID] = tblStueckliste.[FK_StuecklistenName_ID]
) ON tblTeile.[PK_ITEM_ID] = tblStueckliste.[FK_ITEM_ID]
) INNER JOIN tblBuildingStuecklisten ON tblStuecklistenName.[PK_StuecklistenName_ID] = tblBuildingStuecklisten.[FK_StuecklistenName_ID]
) ON tblBuilding.[PK_Building_ID] = tblBuildingStuecklisten.[FK_Workshop_ID]
GROUP BY tblBuilding.GEB
,tblTeile.G_ITEM_German
,tblStuecklistenName.Name_Engl
,tblTeile.SG_ITEM_German
,tblTeile.HK_SG_SP
,tblTeile.ITEM_Details
,tblTeile.REM
,tblTeile.FK_MG_ ID
,tblStueckliste.QTY
,[AnzahlStueckliste] * [QTY]
,[HK_SG_SP] * ([AnzahlStueckliste] * [QTY])
,tblBuilding.NameBuilding
,tblBuildingStuecklisten.AnzahlStueckliste
,tblStuecklistenName.Name_short
ORDER BY tblTeile.G_ITEM_German
,tblTeile.SG_ITEM_German
WHERE tblBuilding.FK_Building_ID IN (1)



Sie dürfen in diesem Board keine Dateianhänge sehen.
Hier das Beziehungsfenster
 

[PhilS]

Ich habe mir mal erlaubt dein SQL-Statement durch einen SQL-Formatter zu jagen und in deinem Beitrag entsprechend anzupassen. - Es ist nur die reine Formatierung (Whitespace) geändert, nichts sonst.

Wenn du dir jetzt das Statement anschaust, und dabei bedenkst, dass die Reihenfolge SELECT - FROM - WHERE - GROUP BY - ORDER BY vorgegeben ist und eingehalten werden muss, dann solltest du die Ursache des Problem schnell erkennen.

[MrB]

Ich habe mit mal erlaubt dein SQL-Statement durch einen SQL-Formatter zu jagen und in deinem Beitrag entsprechend anzupassen. - Es ist nur die reine Formatierung (Whitespace) geändert, nichts sonst.

Wenn du dir jetzt das Statement anschaust, und dabei bedenkst, dass die Reihenfolge SELECT - FROM - WHERE - GROUP BY - ORDER BY vorgegeben ist und eingehalten werden muss, dann solltest du die Ursache des Problem schnell erkennen.

Da sieht man wieder den Unterschied eines Abschreibers wie mir und dem der das richtig gelernt hat.
Ich habe, weil es ja beim ersten mal so funktioniert hat, das einfach reinkopiert und WHERE angehängt. Da aber kein GROUP oder ORDER dabei war ging das, jetzt aber natürlich nicht.

Danke dafür, jetzt geht es wieder etwas voran.

Cord

[ebs17]

Hinweis: Du gruppierst über alle Spalten, die auch im SELECT-Teil aufgeführt sind. Eine Erzeugung eines Aggregates (SUM, MAX, COUNT, ...) ist nicht vorhanden.

Wenn nicht Deine Tabellen mit Duplikaten vollgepackt sind (was ich nach oberflächlicher Betrachtung des Datenmodells eher nicht vermute), ist der Schritt des Gruppierens funktionell überflüssig, muss aber laut SQL-Anweisung ausgeführt werden und ist damit zusätzlicher Aufwand und verschwendet Zeit. Gruppieren ist eine vergleichende Operation, jeder Datensatz der Abfrage gegen jeden anderen, und wenn Du bei den 14 Spalten die Byte-Breite anschaust, ist das eine massive Operation, zumal sehr wahrscheinlich ohne jegliche Indexnutzung.
Wenn dann diese Abfrage für folgende Operationen als Datenbasis verwendet wird, dann werden solche Designfehler weitergetragen und schnell vervielfacht, zu Ungunsten einer möglichen Performance.

Ich sag mal: Schau Dir an, was Du tust.

[MrB]

@ebs17
Habe das Überarbeitet, war sogar doppelt gemoppelt im Bericht nochmal.

Cord