Any() mit UND-Verknüpfung

Manü · 26. April 2016, 10:02

Ahoi,

von einer Methode bekomme ich eine List<DataRow> zurück. Aus dieser möchte ich nun erfahren, ob es Ergebnisse gibt, also Any().
Nun muss ich die Ergebnisse noch etwas genauer Filtern, dass aber über 2 Spalten der DataRows.
In Any() kann ich ja mit einer der Spalten Filtern, aber gibt es dabei auch die Möglichkeit nach zwei der Spalten via UND-Verknüpfung zu Filtern?
Ich kann dazu leider nichts finden, oder suche nur nicht gründlich genug.

So sieht es derzeit aus:

C#-Quellcode

eelFehlzeiten.Result.Where(row => row["F1391008"].Read<DateTime>().Equals(beginnAu));

Und ich möchte an so etwas ran, wie:

C#-Quellcode

eelFehlzeiten.Result.Where(row008 => row008["F1391008"].Read<DateTime>().Equals(beginnAu) && row011 => row011["F1391011"].Read<DateTime>().Equals(endeAu) );

Schon mal vielen Dank für die Hilfe.

*Topic verschoben*

slice · 26. April 2016, 10:27

C#-Quellcode

eelFehlzeiten.Result.Where(row => row["F1391008"].Read<DateTime>().Equals(beginnAu) && row["F1391011"].Read<DateTime>().Equals(endeAu) );

ErfinderDesRades · 26. April 2016, 10:46

was ist das für eine komische .Read<T> - Methode - ist das eine Object-Extension zum Casten?

Und mit typisierten DataRows kannst du nicht arbeiten? - das wäre eleganter und sicherer.

Manü · 26. April 2016, 11:47

@slice Das funktioniert so leider nicht, dass wäre nur mein Gedanke dazu.

@ErfinderDesRades Jap ist es ... Was zurück kommt kommt zurück, da ist nicht viel dran zu ändern.

Derzeit muss ich halt via .Where() Filtern und dann das Ergebnis mit Any() weiter filtern. Ich find das ziemlich unelegant.

EaranMaleasi · 26. April 2016, 12:04

@Manü In deinem Text schriebst du, du möchtest nach 2 Spalten Filtern. Das wäre mit der Lösung von @slice möglich. In deinem Beispiel scheinst du aber nach 2 Spalten 2 verschiedener Rows Filtern zu wollen.

Was also möchtest du nun tun?

ErfinderDesRades · 26. April 2016, 12:16

unabhängig von EaranMaleasis Frage würde ich die .Read<T>() - Extension .As<T>() nennen, denn sie macht fast dasselbe wie das as - Schlüsselwort - ein Namenskonflikt würde dabei trotzdem nicht entstehen.

Readen ist was anneres als Casten, aber

Nomen est Omen!

Manü · 26. April 2016, 14:03

@EaranMaleasi Ach verdammt ... jetzt sehe ich meinen Fehler erst -.- ... stimmt da hat sich was vom rum probieren eingeschlichen
Danke es läuft
Und eigentlich wollte ich nicht Where() sondern Any()
Also:

C#-Quellcode

eelFehlzeiten.Result.Any(row => row["F1391008"].Read<DateTime>().Equals(beginnAu) && row["F1391011"].Read<DateTime>().Equals(endeAu));

@ErfinderDesRades Read liefert bei Fehlschlaf einen Default-Wert zurück, mit dem Equals weiter arbeiten kann, As() würde mir in dem Fall Null zurück geben und eine Exception werfen.

ErfinderDesRades · 26. April 2016, 14:16

und DateTime hat auch einen == - Operator (Equals ist hässlich und macht bischen was anneres)

käme dann so raus:

C#-Quellcode

eelFehlzeiten.Result.Any(row => row["F1391008"].As<DateTime>() == beginnAu && row["F1391011"].As<DateTime>() == endeAu);

Manü · 26. April 2016, 14:41

Bei == würde wohl das Risiko bestehen, ein falsches Ergebnis zu erhalten, da hier zwingend nur der reine Content verglichen werden sollte.

ErfinderDesRades · 26. April 2016, 14:55

was ist der "reine Content" eines DateTime-Objekts? Wie sähe "unreiner Content" aus?

Manü · 26. April 2016, 15:10

Mit der Reinheit hat das nix zu tun ... es geht eher darum, dass == doch die Instanz mit prüft, was wohl zu "falschen" Ergebnissen führen kann.

ErfinderDesRades · 26. April 2016, 15:26

"== doch die Instanz mit prüft" ? hä?

== prüft, ob 2 Objekte sich gleichen, und zwar entsprechend der Implementation des == - Operators dieser Klassen/Structuren.

Du meinst evtl, dass die Referenz-Identität überprüft wird - dem ist aber nicht so, denn DateTime ist kein Referenz-Typ, sondern ein Value-Typ (eine struct).

Langer Rede kurzer Sinn: == ergibt true, wenn beide DateTime-Objekte denselben Zeitpunkt darstellen - nicht mehr und nicht weniger.

Pinki · 26. April 2016, 15:27

ErfinderDesRades schrieb:

Equals ist hässlich und macht bischen was anneres

1. "ist hässlich" das ist Geschmackssache
2. Wird hier überhaupt nichts anders gemacht guckst du referencesource.microsoft.com/…ib/system/datetime.cs,588

Manü schrieb:

doch die Instanz mit prüf

Wenn du damit die Referenz meinst, nein. DateTime ist ein value type und kein reference type. Außerdem kann es bei solchen Sachen auch helfen sich den Source anzuschauen, denn wie man hier referencesource.microsoft.com/…b/system/datetime.cs,1225 sehen kann wird der == Operator überladen und es wird über InternalTicks verglichen.

Ob du nun Equals oder == nimmst ist Geschmackssache in diesem Fall.

ErfinderDesRades · 26. April 2016, 15:30

nein, denn .Equals() akzeptiert beliebige Datentypen, während == typsicher ist.

Pinki · 26. April 2016, 15:34

Du redest von der Equals Methode der Object Klasse. DateTime implementiert allerdings auch IEquatable<T> ;). Guckst du referencesource.microsoft.com/…lib/system/datetime.cs,57 und referencesource.microsoft.com/…ib/system/datetime.cs,595

ErfinderDesRades · 26. April 2016, 15:45

jo - stimmt auch wieder.
Also Geschmacksache, was man schöner findet

C#-Quellcode

var nichtMeinGeschmack = date1.Equals(date2);
//oder
var eherMeinGeschmack = date1 == date2;

nein doch nicht!
Weil das Überladungen sind, wird der Compiler bei Type-Mismatch einfach auf Object.Equals() umschalten - statt zu meckern. Es kann also sowas passieren:

C#-Quellcode

var garNichtMeinGeschmack = date1.Equals("11.9.zweitausendEins");

WhitePage · 26. April 2016, 15:47

ErfinderDesRades schrieb:

nein, denn .Equals() akzeptiert beliebige Datentypen, während == typsicher ist.

Wie ich den Code verstehe, hat EDR Recht, es gibt doch zwei Equals:

C#-Quellcode

public override bool Equals(Object value) {
if (value is DateTime) {
return InternalTicks == ((DateTime)value).InternalTicks;
}
return false;
}
public bool Equals(DateTime value) {
return InternalTicks == value.InternalTicks;
}

EaranMaleasi · 26. April 2016, 15:56

Jou, aber wie wir sehen, wird das Object.Equals überschrieben(overridden?), und nicht einfach nur überladen.
Ergo wird nie auf Referenzgleichheit geprüft, da das Object.Equals() niemals aufgerufen wird, wenn man meinDTobject.Equals("ein string") aufruft. man bekommt direkt false zurück, da der Datentyp nicht stimmt.

Im Endeffekt machen == und DateTime.Equals() exakt das selbe. Die InternalTicks vergleichen.

WhitePage · 26. April 2016, 16:01

Wie ich es verstehe, überschreibt die erste Routine die Object.Equals(), also wird sie aufgerufen, wenn man etwas anderes als DateTime übergibt. Klar kommt da False zurück. Aber ich dachte, EDR ging es darum, dass es bei == sofort knallen würde, bei Equals würde man denken, die Daten sind ungleich.

ErfinderDesRades · 26. April 2016, 16:04

noch einmal: Nein!

C#-Quellcode

date1 == "hallo Welt"

kompiliert nicht, ist also typsicher.

C#-Quellcode

date1.Equals("hallo Welt")

kompiliert, returnt false.

Das ist manchmal tückisch

C#-Quellcode

var dateInput = "11.9.2001";
var date1 = DateTime.Parse(dateInput);
//
var b = date1.Equals(dateInput); // kompiliert, läuft, bringt falsche (naja - unerwartete) Ergebnisse - und Doofi wundert sich irgendwann, dass der Vergleich false ergibt, obwohls derselbe Input ist
//hingegen
var b = date1 == dateInput; // kompiliert nicht, und zwingt Doofi, sich sofort zu wundern, und in Ordnung zu bringen

Any() mit UND-Verknüpfung

Any() mit UND-Verknüpfung

C#-Quellcode

C#-Quellcode

C#-Quellcode

C#-Quellcode

C#-Quellcode

ErfinderDesRades schrieb:

Manü schrieb:

C#-Quellcode

C#-Quellcode

ErfinderDesRades schrieb:

C#-Quellcode

C#-Quellcode

C#-Quellcode

C#-Quellcode

Tags

Ähnliche Themen

7 Benutzer haben hier geschrieben