AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken C# SProc misslungen: multiple rows in singleton select

SProc misslungen: multiple rows in singleton select

Ein Thema von Jürgen Thomas · begonnen am 20. Jul 2006 · letzter Beitrag vom 31. Jul 2006
Antwort Antwort
Seite 2 von 2     12
Jürgen Thomas

Registriert seit: 13. Jul 2006
Ort: Berlin
750 Beiträge
 
#11

Re: SProc misslungen: multiple rows in singleton select

  Alt 30. Jul 2006, 14:53
Danke an alle,

mit den letzten Hinweisen bin ich fast am Ende angekommen:
Zitat von dataspider:
SELECT TMP$USER_HOST FROM TMP$ATTACHMENTS WHERE TMP$USER = USER INTO :Computer_Name;
Dies liefert in der konkreten Situation tatsächlich mehr als einen Datensatz und führt deshalb zu dem Fehler (es hat also nichts mit den SP-Rückgabewerten oder dem Suspend zu tun, wie ich gedacht hatte).

Zitat von dataspider:
TMP$ATTACHMENTS erzeugt für jede Verbindung einen Datensatz.
Wenn sich der gleiche User 2 mal verbindet, liefert dann dein Select evtll 2 Records?
Die Lösung kann nur darin liegen, auch Computer_Name als Input-Parameter zu übergeben.

Zitat von dataspider:
Das Suspend kannst du bei der Fehlersuche vergessen. Da in Interbase auch Selected Procedures unterstützt werden, kannst du Suspend beliebig oft aufrufen. Es produziert keine Fehlermeldung. Der letzte zugewiesene Wert vor dem Suspend wird zurückgegeen.
Eben - deswegen bin ich wegen der Fehlermeldung und Hinweisen, die sich auf Suspend bezogen, durcheinander gekommen.

Zitat von Elvis:
Hier ist mal ein möglichst minimalistischer Ansatz, der mit dem Firebird DataProvider laufen sollte.
Code:
public static void LogbuchStart(IDbConnection connection,
                                int          datenNr,
                                int          selectionNr,
                                out int      neuId,
                                out bool     neuerMonat) //  und so weiter
Danke, so werde ich es machen. Bisher wollte ich mehrere Verfahren, die sich nur wenig unterscheiden, in einer Methode zusammenfassen und nur durch die Parameter unterscheiden; z.B.:
Code:
BdpCommand cmd = Connect.CreateCommand();
switch(Variante) {
case 1: cmd.CommandText = "Logbuch_Start"; cmd.Parameters.Add(...); break;
//  usw. }
try      {
    Connect.Open();
    cmd.ExecuteNonQuery();
    //  Parameter auswerten   }
catch (Exception ex)   {
    MessageBox.Show( "Fehler bei VS-Interna",
        cmd.CommandText + Environment.NewLine + ex.Message, System.Drawing.SystemIcons.Error);
}
finally { Connect.Close(); }
Das wird bei unterschiedlichen Parametern schnell unübersichtlich; also sind getrennte Methoden - wie von Dir vorgeschlagen - praktischer.

Mit einer Methode, die ich nach Deinem Vorschlag angepasst habe, klappt es jetzt fast vollständig. Nur folgendes Problem bleibt noch: "Neuer_Monat" ist auch in der SP ein boolean-Parameter. Aber die Auswertung klappt nicht:
Code:
BdpParameter param = cmd.Parameters[5];
if (param.Value != null && param.Value != DBNull.Value)
     b0 = (bool) param.Value; //  -- hier knallt es
else b0 = false;
liefert die Fehlermeldung:
Zitat:
Die angegebene Umwandlung ist ungültig.
Der Debugger zeigt deutlich die Problemstelle. Ich finde aber in der SDK-Doku keinen Weg, um param.Value zu einem bool-Parameter zu machen. Kann ich auch dazu noch einen Tipp bekommen?

Danke! Jürgen
#D mit C# für NET, dazu Firebird
früher: Delphi 5 Pro, Delphi 2005 Pro mit C# (also NET 1.1)
Bitte nicht sauer sein, wenn ich mich bei Delphi-Schreibweisen verhaue; ich bin inzwischen an C# gewöhnt.
  Mit Zitat antworten Zitat
Elvis

Registriert seit: 25. Nov 2005
Ort: München
1.909 Beiträge
 
Delphi 2010 Professional
 
#12

Re: SProc misslungen: multiple rows in singleton select

  Alt 31. Jul 2006, 04:26
Zitat von Jürgen Thomas:
Nur folgendes Problem bleibt noch: "Neuer_Monat" ist auch in der SP ein boolean-Parameter. Aber die Auswertung klappt nicht:
Code:
BdpParameter param = cmd.Parameters[5];
if (param.Value != null && param.Value != DBNull.Value)
     b0 = (bool) param.Value; //  -- hier knallt es
else b0 = false;
liefert die Fehlermeldung:
Zitat:
Die angegebene Umwandlung ist ungültig.
Der Debugger zeigt deutlich die Problemstelle. Ich finde aber in der SDK-Doku keinen Weg, um param.Value zu einem bool-Parameter zu machen. Kann ich auch dazu noch einen Tipp bekommen?
Jupp, nachdem du sagst wie du BOOLEAN defniert hast. Ist das nicht eine domain, die eigentlich auf einen Integer zeigt? Wenn sie auf einen SmallInt zeigt, musst du natürlich den passenden DbType.Int16 nehmen.
Außerdem ist deine Fehlerbehandlung IMHO furchtbar, denn IMHO dürfte so eine Funktion keine Exception schlucken um dann eine generische zu werfen.
Robert Giesecke
I’m a great believer in “Occam’s Razor,” the principle which says:
“If you say something complicated, I’ll slit your throat.”
  Mit Zitat antworten Zitat
Jürgen Thomas

Registriert seit: 13. Jul 2006
Ort: Berlin
750 Beiträge
 
#13

Re: SProc misslungen: multiple rows in singleton select

  Alt 31. Jul 2006, 07:00
Zitat von Elvis:
Jupp, nachdem du sagst wie du BOOLEAN defniert hast. Ist das nicht eine domain, die eigentlich auf einen Integer zeigt? Wenn sie auf einen SmallInt zeigt, musst du natürlich den passenden DbType.Int16 nehmen.
Intern (in Interbase) stimmt das natürlich weiterhin, aber nicht mehr aus Sicht des Entwicklers:
Zitat von DataDef.pdf Seite 4-1 ff.:
InterBase supports the following datatypes:
BOOLEAN 16 bits
• Represents truth values TRUE, FALSE, and UNKNOWN
• Requires ODS 11 or higher, any dialect
Also müsste der Rückgabewert auch von BDP als bool verstanden werden. Ich kann natürlich (wie bei früheren IB-Versionen und wie Du es gemacht hast) den int-Wert 1 als true und alles andere als false interpretieren; aber eigentlich sollte der "richtige" bool-Wert abgefragt werden können.

[/edit]Oder sollte ich davon ausgehen, dass der Borland Data Provider die Datentypen der Borland-Datenbank Interbase nicht genau genug kennt?

Zitat von Elvis:
Außerdem ist deine Fehlerbehandlung IMHO furchtbar, denn IMHO dürfte so eine Funktion keine Exception schlucken um dann eine generische zu werfen.
Tut mir leid, aber das musst Du mir näher erläutern:

Ich bin Einzelkämpfer und habe nur durch Literatur und try-and-error gelernt; es fehlten mir immer die Kontakte mit anderen Programmierern. Also weiß ich oft nicht, was furchtbar ist.

Ablauffehler versuche ich durch entsprechende vorherige Prüfungen zu vermeiden. Da es aber - wie hier zu sehen war - trotzdem zu unerwarteten Fehlern kommen kann, fasse ich in einem try-except-finally-Block alles zusammen, was zu einem Ablauf gehört.

Da ich die Methoden noch trennen werde (wie ich in meinem letzten Beitrag geschrieben habe), werde ich vermutlich auch die Auswertung der Rückgabewerte verlagern. Das jetzt ist noch eine Testsituation.

Der catch-Block soll natürlich der eigenen Fehlerbehandlung dienen. Dennoch möchte ich die ursprüngliche Fehlermeldung kennen (das halte ich auch für sinnvoll, wenn sich der Endanwender meldet). Da der catch-Block nur für Notfälle da ist, verzichte ich auch weitgehend auf die Unterscheidung der Exception-Typen.

Bitte sage mir, wie Du Dich in meiner Situation verhalten würdest. Jürgen
#D mit C# für NET, dazu Firebird
früher: Delphi 5 Pro, Delphi 2005 Pro mit C# (also NET 1.1)
Bitte nicht sauer sein, wenn ich mich bei Delphi-Schreibweisen verhaue; ich bin inzwischen an C# gewöhnt.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:58 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz