![]() |
Re: SProc misslungen: multiple rows in singleton select
Danke an alle,
mit den letzten Hinweisen bin ich fast am Ende angekommen: Zitat:
Zitat:
Zitat:
Zitat:
Code:
Das wird bei unterschiedlichen Parametern schnell unübersichtlich; also sind getrennte Methoden - wie von Dir vorgeschlagen - praktischer.
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(); } 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:
liefert die Fehlermeldung:
BdpParameter param = cmd.Parameters[5];
if (param.Value != null && param.Value != DBNull.Value) b0 = (bool) param.Value; // -- hier knallt es else b0 = false; Zitat:
Danke! Jürgen |
Re: SProc misslungen: multiple rows in singleton select
Zitat:
Außerdem ist deine Fehlerbehandlung IMHO furchtbar, denn IMHO dürfte so eine Funktion keine Exception schlucken um dann eine generische zu werfen. |
Re: SProc misslungen: multiple rows in singleton select
Zitat:
Zitat:
[/edit]Oder sollte ich davon ausgehen, dass der Borland Data Provider die Datentypen der Borland-Datenbank Interbase nicht genau genug kennt? Zitat:
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 |
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:35 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz