ADO.Net / Ist WIN7 toleranter als WIN XP ???

Hallo, ich habe schon ab und zu mal zickige Vorfälle in meinen Anwendungen gehabt, die bei WIN7 ohne Probleme funktionieren, aber in WINXP rummacken.

Das Problem ist ja, ich entwickle in WIN7. Wir haben aber noch Systeme die arbeiten mit WINXP, 😦

Diesen Fehler habe ich dann auch nur gefunden, weil ich eine virtuelle Maschine mit WINXP habe, und den Code mal dort gedebuggt habe.

Nun mal ein aktuelles Beispiel. Ich sichere Produktionsdaten. Die können später wieder gesichtet werden. Die Daten (jeder Auftrag ein Datensatz) werden in einem DataGrid angezeigt.
Bei Doppelclick wird der Datensatz geöffnet und in Oberfläche dargestellt, außerdem wird eine Datei in einem Textfeld angezeigt. Das funktioniert in WIN7 wunderbar. In WINXP nicht.

Hier mal der Code wo das passiert:

 //// Auftragsnummer auslesen
                   string ordercode = ((DataRowView) (dataGrid.SelectedItem))["Auftragsnummer"].ToString();

//// Von der Kopftabelle über die Auftragsnummer den Dateinamen ausfindig machen und die Datei dann einlesen und darstellen zu können
                   //// ==> In WIN7 funktioniert das, WINXP akzeptiert das nicht, das muss .Select("Auftragsnummer LIKE '" + ordercode + "'") angegeben werden
                   DataRow[] datarows = VfDaten.dSetVfReini.Tables[0].Select("Auftragsnummer = '" + ordercode + "'");

Also wie im Code beschrieben, muss ich für WINXP den "LIKE"-Operator verwenden. Ist doch komisch oder? Kann man die Toleranz der Systeme irgendwo einstellen?

Dann habe ich noch eine andere Applikation. Auf den WINXP-Maschinen läuft die ohne Probleme.
Aber in der WIN7-Maschine tut sich in der Oberfläche nach einer gewissen Zeit nichts mehr. Jetzt ist mir aufgefallen, dass dieser Zustand in WIN7 passiert, wenn die Applikation den Vollbildschirm einnimmt. Wenn ich das Fenster etwas minimiere, läufts auf WIN7 einwandfrei.
Komisch, oder?
Habt ihr auch solche Phänomene?

Bin schon gespannt was mich da noch bei WIN8 erwartet.

Vermutlich ist das ein Fehler aus Deiner falschen Anwendung von ToString, anderen Ländereinstellungen, kombiniert mit zwei unterschiedlichen .NET Versionen.
Deswegen, da ToString-Returnwerte niemals garantiert sind, verwendet man auch die entsprechenden Eigenschaften, statt ToString zu missbrauchen.

Das andere kann ebenfalls durchaus aufgrund einer suboptimale Programmierung entstehen, die bei verschiedenen .NET Versionen dann negativ zur Geltung kommen.
Deswegen hoffe ich, dass Du diesen schlechten Stil von ToString und Co nicht wirklich führst, sondern immer die entsprechenden Eigenschaften verwendest.

Vermutlich ist das ein Fehler aus Deiner falschen Anwendung von ToString, anderen Ländereinstellungen, kombiniert mit zwei unterschiedlichen .NET Versionen.
Deswegen, da ToString-Returnwerte niemals garantiert sind, verwendet man auch die entsprechenden Eigenschaften, statt ToString zu missbrauchen.

Also, ich habe in beiden Systemen gedebuggt (WIXP und WIN7 System) und als "ordercode" war jedesmal ein eindeutiger Wert ohne Leerzeichen oder sonstiges drin. Sollte das deiner Meinung nach dann immer noch der Grund sein, das bei WINXP "kein Datensatz" gefunden wird?

Das andere kann ebenfalls durchaus aufgrund einer suboptimale Programmierung entstehen, die bei verschiedenen .NET Versionen dann negativ zur Geltung kommen.
Deswegen hoffe ich, dass Du diesen schlechten Stil von ToString und Co nicht wirklich führst, sondern immer die entsprechenden Eigenschaften verwendest.

In beiden Systemen ist die Vorraussetzung das FW 4.0 installiert sein muss.

Immer lag es am Programmierer und der falschen Anwendung; nie am Framework. ){gray}

Ich denke auch, das Problem sitzt meistens vor dem Computer

DataTable.Select acts diffrent in win7 and winXP
Nur mal um eines der vielen Google Treffer zu diesem Thema; mit gleichem Hinweis.

Trotzdem beachtest Du nirgends die Lädnereinstellungen, bei so schmutzigen String-Schustereien. Wieso nicht die dafür vorgesehenen Eigenschaften des Objekts nutzen?
Mein Kollege würd nun sagen "bei so einem Code muss man sich auch nicht wundern".

Sehe ich genau so.
Der Code zeigt genau was man niemals machen sollte wenn man professionelle SW Entwickelt.

Ok Werde mich an die Regeln halten. Wie würde das eurer Meinung nach aussehen, wenn man in einem internationalen Unternehmen eine Anwendung erstellt, in der "en-US" der Standard ist und man Datenbanktabellen erstellt? Würdet ihr alles komplett auf "US" einstellen?
Es geht ja dann auch um Eingabefelder die deziamale Eingaben erfordern, Datenfelder in Datenbanken mit Typisierung "float" usw?

Das hat mit der Datenbank nichts / wenig zutun.

Datenbanken sollte man immer Länderneutral entwickeln.
Sprich zB englische Formate bei Gleitkommazahlen (einfach weils Default is), Datetime nur UTC etc...

Das was Dir Probleme macht ist vor allem dieses Casting

string ordercode = ((DataRowView) (dataGrid.SelectedItem))["Auftragsnummer"].ToString();

Und Query auf DataTables; das ist so ne Sache.
Ich bin eh kein Freund von diesen undurchsichtigen Dingen wie DataTable. Aber das sehen andere anders.

DataTables haben schon manchmal ihre Berechtigung, vorallem wenn man langsame Leitungen hat.

@oehrle:
Als erstes solltest du Grundlagen nachholen. Gerade der Unterschied zwischen Casting und Converting scheint bei dir nicht so bekannt zu sein.

Und wenn Du dir mal [Artikelserie] SQL: Parameter von Befehlen durchsiehst, dann wird dir auch die Frage nach der internationalisierung klar sein.