if Abfrage funktioniert nicht richtig

[Juelin]

Hallo Gemeinde,
ich lese eine Datenbank mit den Feldern (Nachname, Vorname, Geburtsdatum) aus. Sortiert nach Nachname, Vorname und Geburtstag.
Das funktioniert auch alles.
Nun will ich wissen, wann sich eine Person ändert. (siehe IF-Abrage Text Bold).
Aber obwohl im Debug der Inhalt der Felder alle gleich sind trifft die IF-Abfrage zu.
Keine Ahnung warum:

    public void dbTabellenEintraegeArray()
        {
        int a = 0;
        String x;
        String[] dbgelesen = new String[999999];
        VitalShowController.anzeintraege = 0;
        if (dbOpen == 1)
            {
            boolean l = true;
            boolean g;
            dbRet = 0;
            String nachname;
            String vorname;
            String geburtsdatum;
            String mnachname = "";
            String mvorname = "";
            String mgeburtsdatum = "";
            try
                {
                Statement befehl = verbindung.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);
                ResultSet rs = befehl.executeQuery(dbBefehl);
                while (l)
                    {
                    rs.next();
                    g = rs.isAfterLast();
                    if (g)
                        {
                        l = false;   
                        }
                    else
                        {
                        nachname =rs.getString("Nachname");
                        vorname =rs.getString("Vorname");
                        geburtsdatum =rs.getString("Geburtsdatum");
[B]                        if ((nachname != mnachname) || (vorname != mvorname) || (geburtsdatum != mgeburtsdatum))[/B]
                            {
                            x = vorname+" "+nachname+" "+geburtsdatum;
                            dbgelesen[VitalShowController.anzeintraege] = x;
                            VitalShowController.anzeintraege++;
                            mnachname = nachname;
                            mvorname = vorname;
                            mgeburtsdatum = geburtsdatum;
                            }
                        a++;   
                        }
                    }
                rs.close();
                }
            catch(SQLException err)
                {
                dbRet = 5;   
                }
            }
        else
            {
            dbRet = 6;   
            }
        if (VitalShowController.anzeintraege > 0)
            {
            VitalShowController.eintraege = new String[VitalShowController.anzeintraege];
            for (a=0; a<VitalShowController.anzeintraege; a++)
                {
                x = dbgelesen[a];
                VitalShowController.eintraege[a] = x;
                }
            }
        }

Habe mal im Debuger nach" dbgelesen[VitalShowController.anzeintraege] = x;" gestoppt
und die Variablen vom debuger sind in bild1..

Wer kann mir das erklären?

Danke umd Gruß
Jürgen

 

[Oneixee5]

Strings vergleicht man normalerweise nicht mit == oder !=. Da Strings Objekte sind, vergleicht man diese mit "test".equals("test) oder !"test".equals("test) oder auch Objects.equals(s1, s2).

Laden…

www.baeldung.com

 

[Oneixee5]

Noch ein ungefragter Hinweis, diesen Code kannst du einfach ersetzen:

                while (l)
                    {
                    rs.next();
                    g = rs.isAfterLast();
                    if (g)
                        {
                        l = false;   
                        }
                    else
                        {
                        ...

durch:

                while (rs.next()) {
                    
                    //-> other code
                    
                }

Wenn du deinen Code entsprechend der coding Richtlinien für Java formatierst, solltest du das besser erkennen können.

 

[Juelin]

Danke Oneixer5,
das hat geholfen.
Muss man aber auch dran denken wenn man Strings vergleicht.
Das finde ich blöd.
Alles Gute und Gruß
Jürgen

 

[Robert Zenz]

Das finde ich blöd.

Das liegt daran weil es Objekte sind, keine primitiven Werte. Bei Objekten vergleicht == immer nur ob es sich um die selbe Instanz handelt.

 

[Oneixee5]

Muss man aber auch dran denken wenn man Strings vergleicht.

Das ist eigentlich ganz einfach: keine Operatoren auf Objekte anwenden. Das überladen von Operatoren ist in Java nicht gewollt. Wenn du etwas besser in der Materie bist, dann wirst du Primitive nur noch selten direkt verwenden, denn diese sind eigentlich der Sonderfall.

 

[M.L.]

Strings vergleicht

Lt. KI gibt es dasselbe Prinzip mit Delphi aber auch beim Verwenden des =-Operators und StrCompare

 

[Juelin]

Nein in Delphi habe ich das Problem nicht. ich kann jeden Datentyp im IF vergleichen.
Das regelt Delphi selber.
Gruß
Jürgen

 

[KonradN]

Ist das so? Also klar - man kann jeden Datentyp im IF vergleichen, aber bei Referenztypen findet (in der Regel) nur ein Vergleich der Referenzen statt und kein Vergleich des Inhalts.

Ich bin nicht wirklich tief in Delphi drin, aber Delphi hat Operator Overloading nur für Records und nicht für Klassen:
Operator Overloading (Delphi) - RAD Studio (embarcadero.com)

Records sind auch Wertetypen - somit ist der Vergleich mit equals (=) nur für Wertetypen möglich. Bei Klassen (Referenztypen) ist der Vergleich mit = auch nur ein Vergleich der Referenz (Also bei eigenen Klassen).

Die String Typen (AnsiString, UnicodeString und WideString sind zwar Referenztypen aber haben teilweise auch Verhaltensweisen von Wertetypen. Der Vergleich mit = ist so eine besondere Verhaltensweise, die tatsächlich möglich ist. Und da gibt es wohl auch Abweichungen bei der Speicherverwaltung...

Also ja, Strings kann man dann einfach mit = vergleichen. Das ist aber kein universelles Vorgehen. Und das führt dazu, dass mit Delphi eher unsympathisch ist und ich mich daher dagegen entschieden habe, da mehr Zeit zu investieren. Und natürlich: Meine Erkenntnisse können auch falsch sein, da ich halt nicht zu viel Zeit da rein gesteckt habe.

 

[Juelin]

Hallo Konrad,
Danke für die Antwort. im Prinzip bin ich Deiner Meinung. Arbeite aber seit 2000 mit Delphi, mein erstes war Delphi5. Heute bin ich bei Delphi11.
Könntest Du bitte nochmal im Beitrag "Probleme bei Stage.close()" reinschauen.
Die letzten zwei Einträge von mir.
Wäre schön, wenn Du mir da helfen könntest.
Danke und Gruß
Jürgen

 

[Manul]

Noch ein ungefragter Hinweis, ...

Da wir einmal dabei sind ...

Was auch noch auffällt an dem Code: Das (leider) Pascal-typische Idiom am Methodenanfang erst mal alle möglichen Variablen zu deklarieren (bzw. in Pascal: zu müssen), und diese dann irgendwann in der Methode selbst zu verwenden (und dann teilweise in unterschiedlichsten Kontexten wiederzuverwenden).

In Java hingegen ist das ein Antipattern, welchen den Code eher schlecht wartbar macht, ohne irgendeinen besonderen Nutzen zu bringen.
Grundprinzip sollte hier eher sein:

• Scope von Variablen möglichst klein halten (nur in dem Scope deklarieren wo sie auch verwendet werden)
• Jede Variable hat genau einen Zweck (d.h. nicht an verschieden Stellen für verschiedene Sachen wiederverwenden)

d.h. nicht:

public void foo() {
    int i = 0;
    
    ... 100 Zeilen später ...

    for (i = 0; i < ...; i++) {
        ... do something ...
    }
}

sondern:

public void foo() {
    ... viele Zeilen ...

    for (int i = 0; i < ...; i++) {
        ... do something ...
    }
}

Auch das hier sieht recht dubios aus:

String x;
...
viele Zeilen später...
...
// in der While-Schleife:
x = vorname+" "+nachname+" "+geburtsdatum;
// könnte vermutlich problemlos ersetzt werden durch:
dbgelesen[VitalShowController.anzeintraege] = vorname + " " + nachname + " " + geburtsdatum;

// und später noch mal in einem komplett anderen Kontext zugewiesen:
x = dbgelesen[a];
// auch hier wäre "x" komplett unnötig:
VitalShowController.eintraege[a] = dbgelesen[a];

Und wenn die scope-minimierten Nicht-Schleifenindex-Variablen dann auch noch halbwegs deskriptive Namen kriegen (und nicht bloß "l" ... , "g", "a" oder "x") dann versteht man den Code auch noch 2 Wochen später etwas besser