Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Aufrufen einer TStoredProc (https://www.delphipraxis.net/80528-aufrufen-einer-tstoredproc.html)

Darkchild 10. Nov 2006 13:35

Datenbank: Firebird • Version: 1.5 • Zugriff über: Interbase

Aufrufen einer TStoredProc
 
Hallo,

ich schon wieder :oops: .

Habe jetzt mal eine Frage zu TStoredProc:

Habe eine TStoredProc in mein Datenmodul gepackt, dann in der StoredProc in den Properties in den Einstellungen Params 2 PArameter angegeben und bei StoredProcName den Generator angegeben der in der Firebird 1.5 Datenbank liegt.
Die Aufgabe der StoredProc soll sein eine Automatische ProjektNr. zu Generieren und in einem DBEdit Feld diese dann vorschlagen.

Jetzt weis ich das ich mir eine Schaltfläche aussuchen muss und einen Event ab dem die Generierung erfolgen soll, auch glaube ich zu Wissen das ich mit der Procedure ExecProc () die ganze sache Starten muss, aber von da an habe ich keinen blassen Schimmer mehr wie es weiter geht.
Habe in die Hilfe geschaut, da steht auch nur das ich die Params einstellen soll und vor ExecProc() noch Prepare() aufrufen muss, soweit ok, aber wie geht es dann weiter ?

Gruss
Darkchild

mkinzler 10. Nov 2006 13:47

Re: Aufrufen einer TStoredProc
 
Der Name muß der name einer Stored Procedure sien und kein Generator. In der Stored Procedure kannst du dann auf den Generator zugreifen bzw ihn mit GEN_ID() erhöhen. Aber ich vermute das Ganze wäre durch einen Trigger statt SP besser zu lösen.

Hansa 10. Nov 2006 14:01

Re: Aufrufen einer TStoredProc
 
Das ist nicht viel. Aktuelles Beispiel, wie so prinzipiell aussieht :

Delphi-Quellcode:
SP.ParamByName ('DATUM').AsDate := d;
SP.ParamByName ('BETRAG').AsFloat := b;
NettoSP.ExecProc;
Netto :=ParamByName ('NETTO').AsFloat;
Anhand des Input-Parameters Datum soll die SP wissen, ob sie mit 16 % oder 19 % rechnen soll. Der Output-Parameter ist dann der errechnete Wert und liefert ihn ans Programm zurück. Soll nur z.B. ein Feld in der DB bestückt werden, dann braucht man den nicht mal. Die Parameter müssen der Datenbank natürlich bekannt sein !

Wie mkinzler habe ich auch zuerst an Trigger gedacht. Aber ich glaube, er will da was von Hand setzen. Aber egal wie, es gilt : entweder das Gespann Generator/Trigger oder eben SP. Habe jetzt die Frage nochmals gelesen und da beschleicht mich das dumpfe Gefühl, daß die SP noch gar nicht da sein könnte. :shock: Ich sehe nämlich nur was von Delphi. TStoredProc usw.

Hansa 10. Nov 2006 14:21

Re: Aufrufen einer TStoredProc
 
Das wäre mal das eine, um dem Titel gerecht zu werden. Nun was ganz anderes, habe mal überlegt, wie ich das machen würde. Es geht um Versionsnummern ? Also im Stil 3.41 usw. ? Die soll automatisch hochgezählt und dann angezeigt werden ? Ich würde dafür weder eine SP noch einen Trigger verwenden. Mache doch besser eine eigene Table mit 2 Feldern : Hauptversion, Unterversion und sonst nichts. Nicht mal IDs usw. wären nötig. Dann könnte man einfach ein Dataset verwenden, das eben immer nur upgedated wird. Also den Datensatz lesen -> anzeigen (Unterversion um 1 erhöht anzeigen) -> Vorschlag übernehmen/ändern -> speichern. Alternative 2 : nicht nur ein Datensatz, sondern das Datum der Aktion wird auch mitgeschleppt. Quasi eine Historie, wann welche Version installiert wurde. Leichte Übung : statt update einfach immer insert verwenden.

hoika 10. Nov 2006 14:32

Re: Aufrufen einer TStoredProc
 
Hallo DarkChild,

sag doch erst mal, was du machen willst.
die SP, Generator + Vorschlag haut so nicht hin.

Was ist, wenn er den Vorschlag ablehnt ?
Dann würde beim nächsten Aufruf eine um 1 höhere Zahl drinstehen.

Für deinen Zweck würde ein select max(projektnr) schon reichen,
unabhängig von dem ganzen Kram der Mehrbenutzerprobleme
(2 Nutzer rufen das gleichzeitig auf und wollen speichern)


Heiko

Darkchild 10. Nov 2006 14:46

Re: Aufrufen einer TStoredProc
 
Die Projektnummer setzt sich immer aus dem Datum und einer FortlaufendenNr. zusammen.
In der DB wird der letzte Eintrag ausgelesen und die FortlaufendeNr. wird dann erst von diesem Wert aus um +1 erhöt, also daher sollte es da keine Probleme geben. Die ProjektNr. sieht dann ungefähr so aus 2006111001 oder 20061110001 mal sehen. Aber das ist das was mir das Teil rausgeben soll, von DB Seite her ist das schon alle fertig, muss jetzt halt nur diese StoredProc benutzen um die ganze Sache dann an Delphi zu bekommen und das ganze dann mit einem Event auf der Oberfläche verbinden.

Gruss
Darkchild

mkinzler 10. Nov 2006 16:33

Re: Aufrufen einer TStoredProc
 
Handelt es sich bei der Projektnummer, um den Primärkey? Dann würde ich einen Trigger verwenden.

hoika 10. Nov 2006 17:25

Re: Aufrufen einer TStoredProc
 
Hallo DarkChild,

und wo ist jetzt das Problem ?
Welches Komponente nimmst du ?
Ist es eine selectable oder eine normale SP ?


Heiko

Hansa 10. Nov 2006 19:20

Re: Aufrufen einer TStoredProc
 
Darkchild, ist das da echt Dein Ernst ? :shock: Du versuchst etwas zu machen, was man eine "sprechende Nr." nennt. Der Name hört sich echt komisch an, aber eventuell hätte dein Opa das auch noch so gemacht. :lol: Die haben sich früher Codes ausgedacht und das ergab z.B. ellenlange Artikelnummern. Textilbereich ist immer gutes Beispiel : erst mal eine Art.Nr., dann wurde eine Lieferantennr., die Farbe, die Größe usw. so drangebaut, dass der ders weiß lediglich anhand der reinen Art.Nr. wissen konnte : der sucht ein T-Shirt von XY und zwar in weinrot und Größe XXL. Dann sieht er noch : hinten ist eine 1, also kein T-Shirt, sondern langer Arm. :zwinker:

Bei Deinem konkreten Problem fangen in der Richtung auch schon gleich die Probleme mit dieser Vorgehensweise an : du haust die Felder genauso zusammen, wie die damals. Mittlerweile fehlt aber der Grund dazu ! Ich habe z.B. auf den ersten Blick nicht mal gesehen, wo der Unterschied bei den 2 Bsp.-Nummern liegt. Man sieht tatsächlich heute in der Praxis aber auch noch solche Ansätze. Im konkreten Fall allerdings sind die Probleme in Richtung Trigger usw. so nicht zu lösen. Warum ? Man kriegt durch die Verwurstung von 2 Feldern, zumindest in dieser Weise mit Datum usw., keine fortlaufenden Nummern hin.

Allerdings ist mir jetzt klar, wie der Generator ins Spiel kam. Muss noch ein Bsp. bringen. Die ProjektNr. lautet z.B. jetzt im Moment (Jahr usw. egal) : 101105. 5 steht dabei für laufende Nr. Nicht Jahr ! Was ist jetzt mit dem Generator am Montag ? Beim ersten mal müßte er lauten : 131101. Wie bringe ich nun den Trigger dazu, den genau auf diesen Wert zu setzen ? :shock: Geht nicht. Nimm besser wirklich eine Table mit 2 Feldern, wie bereits gesagt und lasse bloß die Generatoren in Ruhe. :mrgreen:

Die sind nämlich ziemlich dumm. Als einzige unterliegen sie nicht der Transaktionskontrolle. Wert gesetzt, dann ist der eben so. Was heißt : nix Rollback, Commit usw. Könnte tödlich sein für DB. 8) Diese Dinger manuell oder vom Programm aus zu manipulieren, das würde ich mir nicht angewöhnen.

Darkchild 11. Nov 2006 14:40

Re: Aufrufen einer TStoredProc
 
@hansa

Ich verstehe Dich schon, nur muss ich mich an die Sachen halten di ich in der Vorgabe bekommen habe und derjeniege der die Datenbank entwickelt hat will das die Anbindung so aussieht und die Form der ProjektNr. ist die Vorgabe des Kunden der diese in der Form haben möchte.

Meine Aufgabe ist es jetzt halt mit dem was ich habe eine Oberfläche mit einer Funktionalität zu erstellen die von der Bedienung für die Benutzer intuitiev zu benutzen ist.

Aber an dem rest kann "Ich" leider nicht viel ändern.

Aber die StoredProc Funktioniert jetzt, nur die Ausgegbene Nummer weisst noch kleine Fehler auf, wo ich aber von ausgehe das ich entweder einen Falschen wert eingebe oder das der Wert nicht sauber übergeben wird oder das es an der DB liegt, aber das kann ich mir erst am Monatg wieder ansehen.

Aber dennoch Danke für eure Hilfe, sonst hätte ich da wohl noch ein wenig länger gefummelt.

:-D

Gruss
Darkchild

P.S: Und ja, die ProjektNr ist ein PK und wird in einer weiteren als FK benutzt.


Alle Zeitangaben in WEZ +1. Es ist jetzt 00:45 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 by Thomas Breitkreuz