[gelöst] Firebird Sql nach SQLite Sql - Einen Trigger umschreiben

[lcb-User]

Liebe Forengemeinde!

Mit der Hoffnung dass es hier jemanden gibt der sich mit SQLite auskennt, eine Frage zu folgenden Problem.

Eine Firebird Datenbank möchte ich nach SQLite transformieren.
Mit den Sql von SQLite bin ich nicht vertraut.

Ich möchte einen Trigger in der Tabelle AUFTRAG in SQLite schreiben.
In der Firebird Datenbank setze ich seit Jahren diesen code ein:

Code: Alles auswählen

SET TERM ^ ;
CREATE TRIGGER AUFTRAG_SUMME_AI FOR AUFTRAG ACTIVE
AFTER insert POSITION 0

AS
declare variable num double precision;
begin
  select Sum(Preis_Eur)
  from auftrag
  where mappen_id=new.mappen_id
  into :num;
  update mappe
  set Summe_Mappe=:num
  where id=new.mappen_id;
END
^
SET TERM ; ^

Es soll nach einem Ereignis(update,insert,delete)
die mit MAPPE verknüpften Datensätze aus AUFTRAG
die Summe von Preis_Eur bilden und in die Tabelle Mappe in das dafür vorgesehene Feld Summe_Mappe eintragen.

Könnt ihr mir Helfen?
Oder kennt Ihr ein Forum in deutsch in Sachen SQLITE.

LG

[af0815]

Trigger, Stored Procedures, etc. sind extrem von dem verwendeten Datenbankserver (und Version) abhängig. Das macht die Sache nicht so einfach.

SQLite hat Trigger ( https://www.sqlite.org/lang_createtrigger.html ) aber nicht in dem Umfang und Syntax was du suchst. Aber es besteht Hoffnung, oder du löst den Trigger in der App auf und machst es direkt im Code. Ich sehe die meisten Probleme in der deklarierten Variablen 'Num', ich glaube dort könnte es am ehersten Scheitern, weil das Konstrukt kenne ich von SQLite nicht (was nicht viel heisst)

Hast du eine SQlite Verwaltungsoberfläche ? Wenn ja, dann kannst du mal probieren den Trigger mehr oder minder geändert zu übernehmen.

[lcb-User]

Hast du eine SQlite Verwaltungsoberfläche ? Wenn ja, dann kannst du mal probieren den Trigger mehr oder minder geändert zu übernehmen.

Servus af0815

Ich hab SQLiteStudio, mit dem kann man gut arbeiten, aber Du hast wohl 'des Pudels Kern' getroffen.
Genau an dieser Stelle gibt's die erste Fehlermeldung.

oder du löst den Trigger in der App auf

Das kann ich allerdings auch mach.
Danke!

[af0815]

Ein 'sub'select im update könnte die variable vermeiden. Eine verzweifelte Idee. Nein, ich habe schon öfters sowas 'durchgebracht'. SQLite ist zwar nicht meine Stärke, aber einige Erfahrung habe ich mittlerweile damit.

Ich verwende mittlerweile gerne die 'poor man' Version vom MS-SQL (statt SQLite) das auch unter Linux hammermässig läuft. Das ist aber eine andere Sache.

[lcb-User]

Ein 'sub'select im update könnte die variable vermeiden. Eine verzweifelte Idee.

Verzweifelte Idee - wieso?
Das war des Pudels Kern

Lösung!

Code: Alles auswählen

CREATE TRIGGER AUFTRAG_SUMME_AD
         AFTER DELETE
            ON AUFTRAG
BEGIN
    UPDATE mappe
       SET Summe_Mappe = (
               SELECT Sum(Preis_Eur) 
                 FROM auftrag
                WHERE MAPPEN_ID = old.mappen_id
           )
     WHERE id = old.mappen_id;
END;

Super jetzt kann ich weiterarbeiten.
Oder siehst Du mit Deinem geballten Wissen einen Fallstrick

Lieben Dank !

[Socke]

Oder siehst Du mit Deinem geballten Wissen einen Fallstrick

Mit der Variablen kannst du wunderbar Datenerfassung und -fortschreibung trennen. Das Sub-Select macht es nicht unbedingt lesbarer, ist aber valides SQL. Da dein Trigger hier aber nur wenige Zeilen umfasst, ist dieser Aspekt hier nicht ganz so wichtig.

[af0815]

Ich persönlich vermeide Trigger wenn es irgendwie geht, da weiche ich eher auf Stored Procedures aus. Wenn es ohne geht, hat man gewonnen, wenn man das DB-System wechseln muss.

Vor allen entscheide ich mich vor dem endgültigen Design für einen Fat-Server (alles läuft am Server) bei RasPi, Web. Ist es eine reine Multiuser PC Geschichte, dann für Fat-Client und alles läuft dort. Egal welches Format, Trigger werden vermieden, weil sie auch schwer zu Testen/Debuggen sind.

[lcb-User]

Ich bin immer froh wenn ich von Profis lernen kann, und bin ganz still damit ich nichts verpasse. Aber die Frage war und ist immer noch ob ich eine Server Client Anwendung brauche. Mit dem Raspberry war das eine schöne Lernaufgabe. Meine Datenbankanwendung ist wie ein 'alter Knochen für einen Hund' - rumknabbern dann verbuddeln und wenn wieder Lust ausbuddeln und weiter knabbern usw.

Ich hatte mich 1992 mit einer Druckerei selbstständig gemacht. Die ersten 4 Jahre noch in einem Franchise-Unternehmen. Daraus übernahm ich die Buchhaltung und das Rechnungswesen. Die Software wurde von Taylorix gestellt. Als nach 4 Jahren Schluss mit dem Franchise-Unternehmen war und ich auf eigenen Namen arbeitete, hatte ich angefangen unter Delphi4 und Interbase mir eine Alternative zusammenbauen. Meine ältersten Daten in der Datenbank sind aus 2001. Beim Umstellen von D'Mark auf Euro und der Neugestaltung der Anwendung mit Delphi7 gingen mir die davor liegenden Daten verloren.

Ich habe ein Windows XP in einer Virualbox laufen auf dem ich immer noch meine Rechnungen damit erstelle. Da macht sich so ein Raspi bezahlt. Egal ob ich auf Linux oder auf Windows arbeite, die Datenbank ist immer die selbe.

Jetzt möchte ich versuchen das auf SQLite umzustellen. Ein größerer Brocken liegt noch vor mir. Rechnung per Report ausgeben. Unter Delphi7 hab ich's sogar auf mehrseitige Rechnungen geschafft, Hab ich zwar nur einmal (mehrseitig) gebraucht.

Ich hab schon die Idee alles was möglich ist am Server machen zu lassen, der kann's am schnellsten, bin ich zumindest der Meinung - lass mich gerne eines Besseren belehren.

[af0815]

Ich bin kein wirklicher Profi, zumindest sehe ich mich nicht als solcher. Ich hatte das Glück in meiner alten Firma etliche Kurse zu MS-SQL von M$ besuchen zu dürfen. Auch Delphi mit Datenbanken durfte ich besuchen. Die Ausbildung hat geprägt, besonders bei M$ ging das sehr in die Tiefen des Servers und wie das wirklich abläuft. War sehr Informativ und hat den Blick geschärft.

Zu SQLite, der hat ein paar Besonderheiten, auf die man vorbereitet sein soll. Sachen die mit Datum zu tun haben, sollte man sich vorher überlegen, welche Variante man verwendet. Bei anderen Datentypen immer das angeben was man haben will bei der Tabellendefinition, SQLIte speichert sehr viel als String intern, verwendet nach aussen aber die Metadaten der Tabellendefinition. Das sollte man Berücksichtigen, dann wird es leichter.

[Joh]

Die Frage, die sich mir da stellt: warum willst du in einer größeren Anwendung von Firebird zu SQLite wechseln?
Gerade, wenn man Warenwirtschaftssysteme erstellt, ist eine gleichzeitige Nutzung von/an mehreren Clients doch zumindest optional vorzusehen. Und da ist SQLite doch ziemlich im Hintertreffen.

Wenns um Portabilität geht: Firebird kann auch Portabel genutzt werden. Embedded Version.
Bei deinem Nutzungsszenario sehe ich erstmal keinen Vorteil von SQLite ggü. Firebird.

Ich habe mich gerade bei einer ähnlichen Umstellung für Firebird entschieden. Noch arbeite ich mit meiner Foxpro-Anwendung anno 1995, die ich im Laufe der Zeit auf Lazarus/Firebird umstellen möchte.
Aber solange ich gg. Geld für andere programmieren kann, stelle ich das eigene Projekt gerne hinten an.

[six1]

Ich habe in meinem letzten, sehr großen Projekt, einen dedizierten Server mit MYSQL und SSH Zugang eingerichtet.
Das System hat etwa 1500 Anwender und ca. 150-200 ständige Verbindungen von Endanwendern.
Es gibt eine WEB API, welche ebenfalls Zugriff von Mobile Geräten über https darauf erlaubt.

Ein Client baut über SSH einen Tunnel auf und tauscht über Port translating einen Zugriff auf MYSQL und auch Zugriff auf SFTP auf.
Die Anwender arbeiten dadurch auf die Datenbank und können Dateien hoch- und runter laden.

Ein Client Zugriff direkt auf eine Datenbank sollte man vermeiden.

[lcb-User]

Die Frage, die sich mir da stellt: warum willst du in einer größeren Anwendung von Firebird zu SQLite wechseln?
Gerade, wenn man Warenwirtschaftssysteme erstellt, ist eine gleichzeitige Nutzung von/an mehreren Clients doch zumindest optional vorzusehen. Und da ist SQLite doch ziemlich im Hintertreffen.

Ich hab das etwas unklar formuliert. Also nur zur Klarstellung, es handel sich hier um eine kleine Anwendung für einen 1-Mann Betrieb.
Es sind 6 Tabellen und ein paar Views
In der Adress-Tabelle hab ich ca. 800 Datensätze
in Mappe-Tabelle(Rechnungen) sind ca 5000 Datensätze
und in der Auftrag-Tabelle ca 8400 Datensätze
dazu gibt's noch drei Tabellen um Rechnungsnummer, Zahlungsziel und firmeneigene Daten zu verwalten.
Da gibt's keine DATEV-Schnittstelle und auch keine Warenwirtschaft.

Wenns um Portabilität geht: Firebird kann auch Portabel genutzt werden. Embedded Version.
Bei deinem Nutzungsszenario sehe ich erstmal keinen Vorteil von SQLite ggü. Firebird.

Nun, unter Windows hast du recht, unter Linux ist die Sache etwas anders. Da ist mir Embedded noch nicht gelungen.

Zu SQLite, der hat ein paar Besonderheiten, auf die man vorbereitet sein soll. Sachen die mit Datum zu tun haben, sollte man sich vorher überlegen, welche Variante man verwendet. Bei anderen Datentypen immer das angeben was man haben will bei der Tabellendefinition, SQLIte speichert sehr viel als String intern, verwendet nach aussen aber die Metadaten der Tabellendefinition. Das sollte man Berücksichtigen, dann wird es leichter.

ja, das hab ich auch schon bemerkt

LG