C5 SQL Afvikling af Init-trigger i SEARCH-løkker

Ikke hvad jeg kender til.

Jeg er også rendt ind den. Rådet er at holde sig til enkelte SET kommandoer i TRG.Init-record for at holde performance og så afvikle mere komplekse ting i TRG.Insert eller i formens Init-Record.

Når kernen opstiller en buffer internt, så kalder den Init-record uanset hvad. Den gør det samme ved en INTRODUCE med direkte opslag, mener jeg.

Måske kan #DisableDbXal / #EnableDbXal hjælpe dig?

-Broholm

P.S. Jeg er 100% enig i, at det ikke giver mening at den kalder triggeren.

DisableDbXal har vi haft problemer med, fordi det kun virker i nogle tilfælde (og rapporter er et af de tilfælde, hvor den ikke gør).

Problemet er at vi snakker en temmelig omfattende brancheløsning og gennemgå alle de steder, hvor vi laver en Introduce, for at sætte standardværdier er fuldstændig uoverskueligt. Derudover skal alle skærmbilleder, der bruger blokkene ændres. Vi bruger en del parameter-/brugeropsatte værdier igennem hele programmet til standardværdier.

Har du prøvet at sende en bug-rapport til MS? Virker som en af de større uhensigtsmæssigheder som burde koste en SP.

Bare til yderligere info, fyrer Init-triggeren også i Native...

Jeg har lavet lidt yderligere tests:
XAL’en ser således ud:

SEARCH FinKart
    PRINT SaldoDKK
END
PAUSE

Og så har jeg sat en
IF NOT Løbenummer THEN
    PRINT Konto
    PRINT Løbenummer PAUSE
ENDIF

I TRG.FinKart.Init

Opretter 3 poster i FinKart
Konto    SaldoDKK
1    1.000,00
2    1.500,00
3    2.000,00

Når jeg afvikler kørslen, kommer mine printsætninger således ud:
""
0    (Pause)
""   
0    (Pause)
""   
0    (Pause)
""
0    (Pause)
1.000,00
1.500,00
2.000,00  (Pause)

Hvis jeg fjerner post nr. 2, ser det således ud:
""
0    (Pause)
""   
0    (Pause)
""   
0    (Pause)
1.000,00
2.000,00  (Pause)

Dvs. at i selve afviklingen af SEARCH-løkken, fyrer Init-triggeren i alt 1 gang mere end det antal poster der bliver ramt af SEARCH-løkken.

En umiddelbar plausibel forklaring kunne være, at Microsoft har valgt at håndtere databaser således:

1. Oprette et midlertidigt objekt i hukommelsen dannet ud fra kartotekets skabelon (kald af init-trigger)
2. Kald af databasen med SELECT statement for hvor mange rækker der er påvirket - for hver række, der returneres, oprettes et nyt objekt til at håndtere næste record (igen et kald af init-triggeren).
3. Når alle objekter er oprettet, kaldes databasen med SELECT statementen som returnerer data og objekterne fyldes med data herfra (fyrer ikke en init-trigger, da objektet allerede er oprettet).

Jeg har prøvet med #DisableDbXal kommandoen - dette hjælper ikke, da disse objektoprettelser stadig kalder Init-triggeren.

Det er en simpel buffer på heapen, der oprettes til at indeholde recorden - der findes ikke een linie objektorienteret kode i kernen. Det blev jo skrevet i slutningen af 80'erne.

Bufferen bliver nulstillet og genbrugt fra record til record i SEARCH'en - der vil simpelthen være alt for meget overhead i at allokere og deallokere den for hver record. Men efter nulstillingen kaldes TRG.Init-record.

Sorry, dårlig formulering - når jeg skriver objekt mente jeg buffer. Men jeg tror ikke helt din forklaring holder vand, fordi triggeren bliver fyret 4 gange _inden_ koden bliver afviklet i search-løkken, hvilket vil sige at koden inde i search-løkken kun ville have adgang til den seneste record i bufferen. (kan også bare være en finurlighed omkring hvordan C5 i praksis timer det).

Hvilket build af kernen tester du på, og hvilke opstartsparametre anvender du?

Jeg synes ikke lige at jeg kan få min native kerne til at gøre det...

Hmm... nu da jeg ville genteste det i Native, sker det kun en gang.

Ligenu kører den Init-triggeren en gang.

Jeg tester således:
Sætter en printsætning ind i TRG.FinKart.Init ved løbenummer 0.
Kører en kontoplan. Efter kontoplanen er løbet igennem alle knoti, kommer print-sætningen.

Build: 4.00SP0 #10 HF005 03052006 (vores udvikling af brancheløsningen er ikke helt up-to-date)
Opstartsparametre: -cDK -$Cus/xxxxxxx -h

Jeg tror ikke jeg testede godt nok - tror det er rapporten der gør noget til sidst i native. Kan ikke genskabe problemet i en XAL-kørsel.