Löschabfrage

[nagelspecht]

Hallo zusammen,

ich benötige Hilfe bei einer Löschabfrage.

Meine Frage, wie muss ich Kriterien bei der Löschabfrage eingeben,
das die Datensätze vom 1.1.2010 bis 31.12.2010 aus der Tabelle gelöscht werden.

Im voraus viele Dank

[ebs17]

Code [Auswählen] Erweitern

DELETE FROM DeineTabelle
WHERE Datumsfeld Between #1/1/2010# And #12/31/2010#

Das ist jetzt aber eine komplette Löschabfrage und nicht nur ein Kriterium.

MfGA
ebs

[nagelspecht]

Vielen Dank für  deine Antwort, leider hat es nicht funktioniert !


[Anhang gelöscht durch Administrator]

[MzKlMu]

Hallo,
Du hast ja auch nichts von dem Vorschlag von Ebs umgesetzt.

[nagelspecht]

Ich habe es so eingetragen wie ebs mir geschrieben hat !

siehe Anhang


[Anhang gelöscht durch Administrator]

[Jonny]

Hallo,

die Lösung von EBS ist der komplette SQL-String und nicht das Selektionskriterium.

Schalte die Ansicht bei der Abfrage auf SQL und dann füge die Lösung von EBS ein.

Datumsfeld von EBS ist bei dir Datum
DeineTabelle von EBS ist bei dir Artikel-Umsatz-Tabelle

Die von dir vergebenen Namen sind allerdings total daneben (entschuldige den Ausdruck)
Datum ist ein reseviertes Wort
Rechenoperanden im Namen sind immer probelmatisch (- ist nicht nur Bindestrich sonder halt Minus)

Gruß

Johann

[DF6GL]

Hallo,

oder einfach

"WHERE Datum"

aus der Kriterienzeile entfernen....  

(Vermeidung von Sonder- und Leerzeichen gilt unabhängig hiervon!)

[Jonny]

Hallo Franz,
wenn ich das bei Word richtig sehe ist das gar keine Löschabfrage.

Dann reicht das Kriterum nicht aus.

Gruß

Johann

[MzKlMu]

@Johann,
doch ist eine Löschabfrage, es gibt ja die Funktionszeile "Löschen".

[ebs17]

Wie wäre es denn, wenn man sich bei Diskussionen auf die SQL-Anweisung und damit auf die SQL-Ansicht beschränkt?

Es ist ja die SQL-Anweisung, die von Jet entgegen genommen  und verarbeitet wird - und nicht irgendwelche Bildchen, Zeilen, Spalten und Klick-Trallala. Also egal, was da getippt oder geklickt wird: Die SQL-Anweisung muss passen. Daher sollte man diese anschauen.

MfGA
ebs

[database]

Hallo,

da hast du zweifelsfrei recht, dennoch gibt es Menschen denen die SQL-Syntax nicht geläufig ist - wie ebenfalls unzweifelhaft zu bemerken ist - und daher auf die Access-eigenen Werkzeuge zurückgreifen.

Ich möchte ja nicht oberlehrermäßig erscheinen aber für ungeübte Menschen ist es meist leichter und verständlicher mit den graphischen Werzeugen der Entwicklungsumgebung zu arbeiten.
Soooo abtun würde ich das dann auch wieder nicht.

[ebs17]

Genau, und Fahrrad fährt man besser mit Stützrädern. Da fällt man nicht so schnell um.

Im Ernst: Wer eine Datenbank entwickelt mit ernsthaften Ansprüchen, sollte sich schon ein wenig dafür interessieren, was er tut. Besser, er weiß, was er tut - wie auch ein Hauptkassierer nicht nur einen Rechner in der Hand halten können sollte, sondern auch das Einmaleins beherrschen muss.

Da einen Freifahrtschein "musst Du nicht, brauchst Du nicht" ohne Not auszustellen halte ich für schädigend. Es gibt unzweifelhaft auch sehr viele, die Hinweise und Ratschläge aufnehmen können und wollen und das auch tun, wenn sie die mit einer plausiblen Begründung bekommen.

MfGA
ebs

[oma]

Hallo ebs,

denke mal an deine  ersten Schritte; hast du da auch gleich SQL beherrscht?
Ich denke auch, dass für Einsteiger und Gelegenheitsentwickler der QBE-Entwurfsbereich eine sehr gute Sache ist.
Nicht alle User im Forum sind prof. DB-Entwickler (und wollen es auch nicht sein) sondern viele entwickeln für private Zwecke oder für eigene kleinere  Anwendungen im Unternehmen!

Natürlich ist der Hinweis zur SQL-Ansicht auch für diese Gruppe gut um sich evt. auf deinem Niveau zu entwickeln

Gruß Oma

[ebs17]

Ich sprach nun nicht davon, den grafischen Abfrageeditor nicht zu verwenden - den verwenden im passenden Rahmen  auch Fortgeschrittene und Profis.

Ich sprach davon, bei Nachfragen, Ergänzungen und Vorschlägen zu Abfragen bevorzugt die SQL-Anweisung zu verwenden - schon weil man da keine Abhängigkeiten und Probleme mit Versionen und Sprachen hat. Außerdem dürfte bspw. ein doppeltes WHERE wie oben im Thread  deutlich weniger vorkommen.

Ich glaube nicht, dass irgend jemand überfordert damit wäre,
- eine vorgeschlagene Anweisung in die SQL-Ansicht zu übernehmen und fremde Bezeichnungen durch eigene zu ersetzen,
- seine eigene vorhandene Anweisung mit einer vorgeschlagenen zu vergleichen und gezielt Unterschiede zu erkennen und zu übernehmen (Text ansehen und analysieren geht an anderer Stelle auch),
- anschließend von der SQL-Ansicht wieder in die Entwurfsansicht umzuschalten und sich das in seiner vertrauteren Welt anzuschauen.

Wenn ich mich aber weigere, eine SQL-Anweisung anzuschauen (und gar dazu ermutigt werde), werde ich wohl nie ein Verständnis oder gar Beherrschen von SQL entwickeln können, was fatal ist. Denn in einer Datenbank sind Abfragen nicht irgendein Spielchen, das man auch mal spielen könnte, sondern die erste und eine wesentliche Verarbeitungsschicht auf die Daten, die in Tabellen liegen. Um darüber hinaus gute und leistungsfähige Abfragen erstellen zu können, kann ich mich nicht auf die "Intelligenz" eines Assistenten verlassen, der einem einfache Schritte abnimmt und Kenntnislosen überhaupt zu lauffähigen (einfachen) Abfragen verhilft.
Zusätzlich würde ich das Bewusstsein darüber schärfen wollen, dass Jet deutlich mehr kann als der grafische Editor erzeugen oder (übersichtlich) darstellen kann. Das beginnt schon bei Unterabfragen und Theta Joins, womit man auch schon bei einfachen Aufgabenstellungen konfrontiert sein kann. Der häufig  anzutreffende Glaube, was im Editor nicht geht, geht nicht, ist also Unsinn.

Was ich eigentlich meine: Warum soll man nicht von Haus aus, also sofort, dem Fragenden mitteilen, wie man es richtig macht und richtig miteinander kommuniziert? Ich denke, es werden nur wenige verbleiben, die sich aus Prinzip oder Unfähigkeit da verweigern und heraus halten.

Nebenbei: Wenn man über Formulardesign zu reden hätte, würde man das sicher auch nicht an Hand eines Formularerstellungs-Assistenten tun.

MfGA
ebs