SELECT SUM(Anzahl*EK) FROM ...

frifri schrieb:

Das das Ergebniss nur für einen Tag gezeigt wird hab ich hiermit geschafft...

Code-Horror mal in Sql
Ein Datum ist ein Datum, und kein String - das gilt auch in Sql.
Der Like-Operator ist für String-Verarbeitung, Datumse gleicht man mit <, >, =, <> ab.
Falls du deine Datumspalte wirklich als Text hinterlegt hast, hast du einen Modellierungs-Fehler in deim Datenmodell, den du unbedingt ausmerzen solltest.

Auch die Benamung deiner Tabellen ist 100% tödlich.

Und welcher Wahnsinnige hat verzapft, dass die ArtikelNummern als String angelegt werden, noch dazu mit unterschiedlicher Länge?
Das schlägt dem Faß die Krone ins Gesicht.soll ich nu lachen oder weinen?
Offensichtlich ist Tabelle2.ArtikelNr dann wieder eine INT - Zahl?

Ja, da ist beim Datenmodell einiges schiefgelaufen, aber wie ich das verstanden habe, kann der TE da nix für, er muss nur auf die bestehenden Daten jetzt seine Lösung draufsetzen. Der Horror eines jeden Coders, hab ich selbst viel zu oft mitmachen müssen.
Ich kann mir sogar vorstellen, wie das mit den Artikelnummern "passiert" sein könnte - auch wenns keine Rechtfertigung sein soll: In der Regel haben Handelsartikel ja eine eindeutige EAN. Diese besteht nicht aus "irgendeiner zufälligen Zahl", sondern enthält vornehmlich einen Länder- und einen Herstellercode, lediglich die letzten x Stellen sind dann vom Hersteller frei wählbar. Vermutlich ist das hier der Grund. In der einen Tabelle steht dann die Hersteller-eigene Artikelnummer, in der anderen Tabelle findet sich der komplette EAN-Code, also mit vorangestelltem Länder- und Herstellercode. Und da diese EAN vermutlich eine bestimmte Länge haben "muss", führende Nullen aber in der Regel bei einem numerischen Wert aber nicht angezeigt werden, hatte sich der Datenbankdesigner wohl gedacht, das einfach in einen String zu klatschen.

Sowas ähnliches hab ich auch mal vorgefunden. Da ging es auch um Artikelnummern für die Produktion. Nach der Fertigung auf einer Maschine sollten die Bauteile mit Etiketten versehen werden, auf die diese Nummer als Barcode gedruckt wird. Und mein Vorgänger, der die Datenbank dazu verzapft hatte (das ist noch "harmlos" formuliert) hat - neben vielen anderen Designfehlern - auch in einer der Tabellen, aber nicht in allen, die Artikelnummer zu eben diesem Zweck mit führenden Nullen versehen in einem String verpackt. Jede Kreuztabellenabfrage - und davon kamen nachträglich einige hinzu - wird somit jedes Mal zu einem Abenteuer, zumal auch noch keine der Tabellen eine Art fortlaufende ID hat und die Verknüpfung ausschließlich über die Artikelnummer funktioniert. (Das Happy End meiner Geschichte: Ich darf mich jetzt richtig austoben, also nicht nur die Anwendung von VC++ 6.0 nach .NET migrieren, sondern komplett neu designen - inklusive Datenmodell.)

Also eine ArtikelNr als String aufzusetzen ist nicht ungewöhnlich. Wie du sagst: Oft sinds ja gar keine Nummern, sondern sind String-Codes, die nach iwelchen Regeln gebildet werden.

Ich denk, der Fehler ist, in der DB eine Beziehung nicht einzurichten, wo tatsächlich eben doch eine Beziehung besteht inne Wirklichkeit.
Hätte man (Beispiel post#1) die Relation zw. Verkäufe-Tabelle und Produkt-Tabelle richtig modelliert mit einer 1:n - Relation, dann hätte die DB von vornherein schon damals erzwungen, dass PrimKey und ForeignKey denselben Datentyp haben, und es wäre später zur Laufzeit auch ühaupt nicht möglich gewesen, Verkäufe einzuspeichern, deren Artikelnummer nicht den ArtikelNummern der Produkt-Tabelle entstammt.
(Und so ganz nebenbei geht erheblich Sql-Performance flöten, weil Sql-Provider sind mordsmäßig optimiert, wenns drum geht, Standard-Relationen auszuwerten - und das geht glaub bei Cint(Mid(Artikel_id, 5, 99) verloren.)

Und dein DB-Designer hat die Tabellen wirklich Tabelle1, Tabelle2 genannt, und Tabelle1.ArbeitsDatum als String angelegt?

Also konstruktiv:

frifri schrieb:

"Datentypen in Kriterienausdruck unverträglich."

Das kann auch von falscher Kriterien-Syntax herrühren, du müsstest mal zeigen, welchen Filter genau du gesetzt hattest, als die Exception kam.
Weil wenn Access aussagt, es sei ein Datum, dann stimmt das meist.

Datumse muss man mit invarianter Kultur formatieren, und müssen glaub in '#' gequoted sein.

Funktioniert Textverkettung durch ​+= eigentlich bei ​Option Strict On auch noch?
Oder akzeptiert dies der Compiler als C#-Kompatibilität?

Saubere Vorgehensweise bei VB:
Mit ​+ addiert man Zahlen. Mit ​& verkettet man Strings.

wenns nach rechten Dingen zugeht, ist der + - Operator Member der String-Klasse im Framework - gilt also für c# + vb.
Wo der & - Spezial-Operator angesiedelt ist, weiß ich nicht.

ich glaub die verhalten sich auch bisserl unterschiedlich.

Klingt plausibel.