SQL Abfragen dauern ewig, Join Problem, Firebird

kein 607
wieder ein 204

Code:
Starting transaction...
Preparing query: Create View vw_kunden(kundennr, belegnr, belegdat, belegart) As
Select k.kundennr,
  b.belegnr,
  b.belegdat,
  b.belegart
From  kunden k
Left  Join beleg b
On  k.kundennr = b.adressnr
And  extract(Year From b.belegdat) = 2014
Prepare time: 0.016s
Plan not available.


Executing...
Done.
274 fetches, 50 marks, 0 reads, 2 writes.
12 inserts, 2 updates, 0 deletes, 29 index, 0 seq.
Delta memory: 20824 bytes.
RDB$RELATION_FIELDS: 4 inserts.
RDB$RELATIONS: 1 inserts. 2 updates.
RDB$VIEW_RELATIONS: 2 inserts.
RDB$USER_PRIVILEGES: 5 inserts.
Total execution time: 0.047s
Preparing query:

Create View vw_belegpos(kundennr, belegnr, belegdat, belegart, posnr, artikelnr) As
Select b.*,
  bp.posnr,
  bp.artikelnr
From  vw_kunden b
Left  Join belegpos bp
On  b.belegnr = bp.belegnr
Prepare time: 0.000s
Plan not available.


Executing...
Done.
389 fetches, 60 marks, 0 reads, 2 writes.
14 inserts, 2 updates, 0 deletes, 52 index, 0 seq.
Delta memory: 4112 bytes.
RDB$RELATION_FIELDS: 6 inserts.
RDB$RELATIONS: 1 inserts. 2 updates.
RDB$VIEW_RELATIONS: 2 inserts.
RDB$USER_PRIVILEGES: 5 inserts.
Total execution time: 0.016s
Preparing query:

Create View vw_artikel(kundennr, belegnr, belegdat, belegart, posnr, artikelnr, steuervk) As
Select t.*,
  a.steuervk
From  vw_belegpos t
Left  Join artikel a
On  t.artikelnr = a.artikelnr
Prepare time: 0.000s
Plan not available.


Executing...
Done.
431 fetches, 57 marks, 0 reads, 0 writes.
15 inserts, 2 updates, 0 deletes, 63 index, 0 seq.
Delta memory: 3584 bytes.
RDB$RELATION_FIELDS: 7 inserts.
RDB$RELATIONS: 1 inserts. 2 updates.
RDB$VIEW_RELATIONS: 2 inserts.
RDB$USER_PRIVILEGES: 5 inserts.
Total execution time: 0.016s
Preparing query:

Select f.kundennr,
  f.belegnr,
  f.belegdat,
  f.posnr,
  f.artikelnr,
  g.f2 As kostenstelle,
  round(Sum(Case
  When f.belegart = 'GU' Then
  f.gesamt * -1
  When f.belegart = 'RE' Then
  f.gesamt
  Else
  0
  End), 2) As umsatz2014
From  vw_artikel f
Left  Join gdidef g
On  g.w0 = f.steuervk
And  g.satzart = 'ST'
Group  By f.kundennr,
  f.belegnr,
  f.belegdat,
  f.posnr,
  f.artikelnr,
  kostenstelle
Error: *** IBPP::SQLException ***
Context: Statement::Prepare(

Select f.kundennr,
  f.belegnr,
  f.belegdat,
  f.posnr,
  f.artikelnr,
  g.f2 As kostenstelle,
  round(Sum(Case
  When f.belegart = 'GU' Then
  f.gesamt * -1
  When f.belegart = 'RE' Then
  f.gesamt
  Else
  0
  End), 2) As umsatz2014
From  vw_artikel f
Left  Join gdidef g
On  g.w0 = f.steuervk
And  g.satzart = 'ST'
Group  By f.kundennr,
  f.belegnr,
  f.belegdat,
  f.posnr,
  f.artikelnr,
  kostenstelle )
Message: isc_dsql_prepare failed

SQL Message : -204
can't format message 13:796 -- message file C:\Programme\firebird.msg not found

Engine Code  : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -204
Table unknown
VW_ARTIKEL
At line 17, column 19


Total execution time: 0.000s
 
Werbung:
Wie gesagt... Vllt. musst du nach dem du die Views erstellt hast noch ein commit einwerfen. Aber das macht für mich überhaupt keinen Sinn... Da die Views sich ja gegenseitig sehen... O.o
 
Du kannst auch die SQL Befehle händisch nacheinander ausführen, wäre das Selbe. Da ich deinen Client nicht kenne würde ich das auch empfehlen.
 
Ein commit? Gut ich glaub ich zieh wieder in eine Höle, ich hab keine Ahnung was das sein soll.^^

Dein Ernst jetzt?

*Richtige* Datenbanken arbeiten mit Transaktionen. Du willst, z.B., Geld von A nach B transferieren, 100 EUR. Das ziehst Du von A ab, update a konto_stand = konto_stand - 100 where kontonummer = ... Und das buchst Du bei b zu, auch vie Update. Soweit klar?

Was passiert, wenn nach dem ersten Update der Strom ausfällt? A und B sind vermutlich nicht wirklich erfreut, wir haben ein schwarzes Loch geschaffen.
Damit das nicht passiert, stecken wir beide Updates in eine Transaktion. Dazu kommt vorher ein BEGIN TRANSACTION und zum Schluß ein COMMIT.
Fällt jetzt nach dem ersten Update der Strom aus, ist alles nach dem BEGIN TRANSACTION hinfällig und es erfolgt ein ROLLBACK der Transaktion.

Das glaube ich hier aber nicht als Ursache, denn solche Aktionen nennet man DDL, Data Definition Language. Dazu gehört alles, was die Stuktur der DB ändert, also Create, Alter und so - und es gibt, soweit ich weiß, nur zwei Datenbanken, die das in einer Transaktion machen können: PostgreSQL und aktuelle Oraggle-Versionen.
 
Könnten wir uns auf den Code konzentrieren? Ich habe leider keine Zeit mit grosartig mit neuen Sachen zu beschäftigen. Tut mir leid wegen dem gebettel aber mir steht das Wasser bis zum Hals.
Ich glaube die Zeit solltest du dir doch lieber nehmen...


Aber das hier sollte es eig. tun:
Code:
Create View vw_kunden(kundennr, belegnr, belegdat, belegart) As
Select k.kundennr,
       b.belegnr,
       b.belegdat,
       b.belegart
From   kunden k
Left   Join beleg b
On     k.kundennr = b.adressnr
And    extract(Year From b.belegdat) = 2014;

Create View vw_belegpos(kundennr, belegnr, belegdat, belegart, posnr, artikelnr) As
Select b.*,
       bp.posnr,
       bp.artikelnr
From   vw_kunden b
Left   Join belegpos bp
On     b.belegnr = bp.belegnr;

Create View vw_artikel(kundennr, belegnr, belegdat, belegart, posnr, artikelnr, steuervk) As
Select t.*,
       a.steuervk
From   vw_belegpos t
Left   Join artikel a
On     t.artikelnr = a.artikelnr;

Commit;

Select f.kundennr,
       f.belegnr,
       f.belegdat,
       f.posnr,
       f.artikelnr,
       g.f2 As kostenstelle,
       round(Sum(Case
                    When f.belegart = 'GU' Then
                     f.gesamt * -1
                    When f.belegart = 'RE' Then
                     f.gesamt
                    Else
                     0
                 End), 2) As umsatz2014
From   vw_artikel f
Left   Join gdidef g
On     g.w0 = f.steuervk
And    g.satzart = 'ST'
Group  By f.kundennr,
          f.belegnr,
          f.belegdat,
          f.posnr,
          f.artikelnr,
          kostenstelle;
 
Werbung:
Ok. Regel Nr. 1: Kenne deinen Feind. Ich kannte ihn nicht. Die Felder zum Begrenzen der Datensätze sind alle in Beleg und BelegPos vorhanden... Mein Hirn ist aus der Schule noch auf völlige Redundanz freiheit Getrimmt. Das verknüpfen dieser 5 Tabellen ist somit garnicht nötig.
Unser Dienstleister hat mir per Remote eben was auf den Bildschirm geknallt was einfach mal funktioniert und das ist dabei nicht mal kompliziert.

Code:
SELECT
   belegpos.adressnr,
   beleg.plz,
   SUM(CASE WHEN (Belegpos.Belegart = 'GU') THEN Belegpos.Gesamt *-1 ELSE Belegpos.Gesamt END) AS umsatz
FROM
   belegpos,
   beleg
WHERE
   belegpos.belegnr = beleg.belegnr AND
  belegpos.belegtyp = 'V' AND
    (
      Belegpos.belegart = 'RE' OR
      belegpos.belegart = 'GU'
    ) AND
  beleg.fibukto = '424242' AND
  (
      belegpos.steuerschl='1234' or
      belegpos.steuerschl='5678' or
      ... --Begrnzung der SteuerSchl
    ) AND
  GETDATE(beleg.belegdat)>'01.01.2014'
GROUP BY
   belegpos.adressnr,
   beleg.plz;
Danke nochmal an dich Distrilec

edit:
Dein letzter Post gibt die Melung
Code:
Engine Code  : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -206
Column unknown
F.GESAMT
At line 11, column 24
Ich bin gerne bereit diesem Ansatz noch zu einem ergebnis zu verhälfen aber ich weiß nicht wie ich dazu zeit finde.
 
Zuletzt bearbeitet:
Zurück
Oben