[Postgres] Rules

[Verwijderd]

Ik ben bezig met een programma waarmee ik mijn CD collectie enigzins kan beheren. Om dit te doen maak ik gebruik van een Postgres database (en een in C# geschreven programma). Nu wil ik echt het volgende in dat programma maken:

Op het moment dat een CD op een bepaalde locatie toegevoegd wordt op een bepaalde kolom in een rij moeten alle onderliggende CD's één plaats naar beneden geschoven worden, maar alleen op het moment dat het stack veld van de betreffende locatie true is.

Nou kan ik dat natuurlijk oplossen in m'n applicatie, maar het leek me handiger om dat binnen de database te doen. Nou weet ik dat Postgres 't begrip rules kent, en ik vroeg me af of het hiermee te bereiken is? Iemand die me misschien een duw in de goede richting kan geven?

[JaQ]

je bedoeld dat je anders wilt sorteren? Dat lijkt me toch echt iets wat je niet met een database actie wilt uitvoeren, maar vanuit je applicatie.

Als je het nou echt wil, moet je je eens gaan verdiepen in plpgsql.

[Verwijderd]

DrFrankenstoner schreef op 04 July 2003 @ 14:28:
je bedoeld dat je anders wilt sorteren? Dat lijkt me toch echt iets wat je niet met een database actie wilt uitvoeren, maar vanuit je applicatie.

Als je het nou echt wil, moet je je eens gaan verdiepen in plpgsql.

Het enige wat er eigenlijk hoeft te gebeuren is het updaten van alle onderliggende CD's en daar het row veld van wijzigen. Het zou aanzienlijk wat schelen als dat binnen de DB kan, in plaats van binnen m'n applicatie, omdat ik anders binnen m'n programma moet gaan opzoeken om welke CD's het precies gaat, en die vervolgens stuk voor stuk updaten. Kan me niet voorstellen dat er geen snellere manier is .

Ennuhm, plpgsql? Moet ik dat lezen als Perl PostgreSQL?

[xoror]

dit gaat zo niet lukken. Je moet een tussen laag tussen je DB en app hebben die jou app signaleert dat er een update heeft plaats gevonden. Maar voor z'n simpele app is dit helemaal niet nodig. refresh gewoon om dezoveel tijd en gebruik order by van de db.

[ACM]

't Klinkt op het eerste gezicht als iets waar Triggers voor bedoeld zijn

plpgsql is een van de procedurele talen die je binnen postgres voor functions enzo kan gebruiken.

[ Voor 41% gewijzigd door ACM op 04-07-2003 14:39 ]

[xoror]

ACM schreef op 04 July 2003 @ 14:38:
't Klinkt op het eerste gezicht als iets waar Triggers voor bedoeld zijn

plpgsql is een van de procedurele talen die je binnen postgres voor functions enzo kan gebruiken.

triggers lossen niets op in dit geval (tenzij je triggers gebruikt om de app te signaleren, maar ik weet niet of dat wel mogelijk is), zoals ik het lees wil hij de change in zijn applicatie weer gegeven hebben als deze zijn uitgevoerd vanaf een andere locatie

[Verwijderd]

xoror schreef op 04 juli 2003 @ 14:35:
dit gaat zo niet lukken. Je moet een tussen laag tussen je DB en app hebben die jou app signaleert dat er een update heeft plaats gevonden. Maar voor z'n simpele app is dit helemaal niet nodig. refresh gewoon om dezoveel tijd en gebruik order by van de db.

ORDER BY? Dat lijkt me niet helemaal werken. Volgens mij moe'k ffies wat duidelijker maken wa'k bedoel . ffies laten zien hoe m'n DB er uit ziet:

cd
- title (pk)
- creationdate
- type
- fk_storedloc (fk)
- fk_currentloc (fk)
- size

location
- location (pk)
- width
- height
- parts
- fitshalfsize
- stack
- homelocation

locationdetails
- fk_cd (fk)
- fk_location (fk)
- part
- column
- row

rental
- startdate (pk)
- followupnr (pk)
- fk_cd (fk)
- fk_firstname (fk)
- fk_lastname (fk)
- enddate

Nu is het dus de bedoeling dat op het moment dat er in de locationdetails tabel een nieuwe CD toegevoegd wordt alle onderliggende CD's op diezelfde locatie (en in dezelfde kolom, als dat nodig is) eentje opgeschoven worden om plaats te maken voor de nieuwe CD. Maar dat moet dus alleen gebeuren als voor die locatie het stack veld op true staat.

[ACM]

xoror schreef op 04 July 2003 @ 14:41:
triggers lossen niets op in dit geval (tenzij je triggers gebruikt om de app te signaleren, maar ik weet niet of dat wel mogelijk is), zoals ik het lees wil hij de change in zijn applicatie weer gegeven hebben als deze zijn uitgevoerd vanaf een andere locatie

De update-queries zijn juist zaken die je heel mooi met triggers op kan lossen en een app signaleren kan ook met triggers trouwens

Dan zit je met listen/notify dingetjes, heeft postgresql "toevallig" ondersteuning voor

[xoror]

ow, dan moet je een trigger hebben. ik dacht dat je het afgebeeld wilde hebben in je c# app op het moment van inserten.

acm: stoere shit dat listen/notify, net even bekeken

[ Voor 20% gewijzigd door xoror op 04-07-2003 14:45 ]

[Verwijderd]

ACM schreef op 04 July 2003 @ 14:42:
[...]

De update-queries zijn juist zaken die je heel mooi met triggers op kan lossen en een app signaleren kan ook met triggers trouwens

Dan zit je met listen/notify dingetjes, heeft postgresql "toevallig" ondersteuning voor

Het gaat in dit geval dus om een INSERT he, geen UPDATE. Maar ik zit ffies te kijken naar de mogelijkheden van een trigger. Nu moet ik alleen even kijken hoe ik er voor zorg dat ik alle onderliggende CD's pak en die ga updaten. Kan ik dat met SQL afhandelen, of moet ik daarvoor toch grijpen naar andere taaltjes?

[Verwijderd]

xoror schreef op 04 July 2003 @ 14:43:
ow, dan moet je een trigger hebben. ik dacht dat je het afgebeeld wilde hebben in je c# app op het moment van inserten.

acm: stoere shit dat listen/notify, net even bekeken

Nee, het is een kwestie van het updaten van de tabellen. In m'n C# applicatie zijn die gegevens namelijk niet eens zichtbaar op het moment van invoegen.

Trouwens, dat listen/notify systeempje klinkt inderdaad ook erg interessant. Is denk ik vooral handig bij multi-user applicaties. Doet een beetje MVC achtig aan .

[xoror]

triggers kan je definieren op (before/after) inserts, update, deletes.

[ACM]

Verwijderd schreef op 04 July 2003 @ 14:45:
Het gaat in dit geval dus om een INSERT he, geen UPDATE. Maar ik zit ffies te kijken naar de mogelijkheden van een trigger. Nu moet ik alleen even kijken hoe ik er voor zorg dat ik alle onderliggende CD's pak en die ga updaten. Kan ik dat met SQL afhandelen, of moet ik daarvoor toch grijpen naar andere taaltjes?

Je zult dan een after insert trigger oid moeten definieren (for each row, waarschijnlijk) en die dan de geschikte update-queries laten formuleren via, bijvoorbeeld, plpgsql.

Als je die queries met enkel de gegevens van het nieuw ingevoerde record kunt afhandelen dan kan het met een trigger. Als je er meer gegevens voor nodig hebt, dan kan je een function definieren en die zowel de insert als de benodigde updates laten uitvoeren.

[Verwijderd]

Hmmz, iets als 't volgende gaat zeker niet werken:

SQL:

UPDATE locationdetails SET row = row + 1
WHERE fk_location = <nieuwe item>.fk_location
AND row < <nieuwe item>.row
AND location.location = <nieuwe item>.fk_location
AND location.stack = 'T'

[ACM]

Hoezo niet? Die nieuwe-item dingen kan je dus juist wel opvragen in je trigger, zie de verschillende voorbeelden in de postgresql-documentatie (zie ook het programmers deel over serverprogramming en daar dan weer het plpgsql/trigger deel enzo)

[JaQ]

Zoiets gaat bijna werken, maar dan wel in een functie. Ik raad je ten zeerste aan om "for each row" te gebruiken, anders kan je NEW.<<kolomnaam>> niet gebruiken en is het risico op integriteitsverlies groter (lang verhaal).

offtopic:
grappig dat ik altijd ACM zie in pl / sql / db topics

[Verwijderd]

DrFrankenstoner schreef op 04 July 2003 @ 14:58:
Zoiets gaat bijna werken, maar dan wel in een functie. Ik raad je ten zeerste aan om "for each row" te gebruiken, anders kan je NEW.<<kolomnaam>> niet gebruiken en is het risico op integriteitsverlies groter (lang verhaal).

offtopic:
grappig dat ik altijd ACM zie in pl / sql / db topics

Mjah, 'k heb al FOR EACH ROW. 'k gebruik alleen een programma'tje om m'n DB mee te bouwen (EMS PostgreSQL Manager Pro), en op het moment dat ik dus die Trigger wil aanmaken zegt ie dat m'n functie niet bestaat, terwijl ik heb opgegeven dat hij een nieuwe functie aan moet maken .

[ACM]

DrFrankenstoner schreef op 04 July 2003 @ 14:58:

offtopic:
grappig dat ik altijd ACM zie in pl / sql / db topics

Hehe, persoonlijke interesse/beroepsmatige interesse/opleidingsmatige interesse/you name it

Maar bij een trigger ben je sowieso, in postgres, verplicht het in een functie te stoppen toch? Of niet als je een SQL-language-based trigger bouwt?

[jochemd]

Pseudocode:

code:

CREATE TRIGGER ..... BEFORE INSERT ON .... FOR EACH ROW

CREATE FUNCTION .....  ...'
BEGIN
    UPDATE locationdetails
    SET row = row + 1
    WHERE row > NEW.row
          AND
          EXISTS (
              SELECT 1
              FROM location
              WHERE stack = TRUE
                    AND
                    location.location = locationdetails.location
              )
          AND
          column = NEW.column;
END;
LANGUAGE ....

Succes!

[ Voor 5% gewijzigd door jochemd op 04-07-2003 15:01 ]

[JaQ]

ACM schreef op 04 July 2003 @ 15:00:
[...]

Hehe, persoonlijke interesse/beroepsmatige interesse/opleidingsmatige interesse/you name it

Maar bij een trigger ben je sowieso, in postgres, verplicht het in een functie te stoppen toch? Of niet als je een SQL-language-based trigger bouwt?

De intresse varianten ken ik (ik verdien er ook m'n geld mee als zelfstandige, maar het blijft ook hobbie)

Of een functie verplicht is weet ik eigenlijk niet eens, maar ik kies altijd wel voor een functie, omdat ik graag mijn logica bij elkaar houd. Ik mis packages, zoals deze in Oracle bestaan dus ook een beetje.. (en ben dus bezig een eigen variant te maken, als je het leuk vind kunnen we daar wel eens een boom over opzetten, maar dan wel in een ander topic )

[xoror]

je kan je funkties toch groeperen per schema ? dan heb je ook soort poor-man's 'oracle packages'.

[JaQ]

xoror schreef op 04 juli 2003 @ 15:06:
je kan je funkties toch groeperen per schema ? dan heb je ook soort poor-man's 'oracle packages'.

Ongeveer... maar niet helemaal... Het grote voordeel van een package is dat de logica dan in de SGA (zeg maar memorry) blijft hangen en dus geen startup overhead geeft etc. (bij het aanroepen dan). Volgens mij gaat postgresql daar iets anders mee om. (vandaar dat er dus geen packages mogelijk zijn tot op heden)

[xoror]

je wilt alleen packages omdat ze dan in het geheugen blijven hangen ???

ik dacht dat de algemene reden om packages te maken was dat je dan
funkties die 'bij elkaar horen' kan groeperen. met die schema's kan je iig vrij goed
oracle packages vertalen naar plpgsql. Daarnaast zal de opstart tijd van z'n stored proc minimaal zijn vergeleken met de tijd die de eigenlijke proc/udf nodig heeft.

[alienfruit]

[flameindepijp]tisch interesse ipv intresse; volgens de klant die net belde (ik schreef het ook verkeerd)[/flameindepijp]

[Verwijderd]

Hmmz, ik kom er niet uit met die triggers. Als 'k vanuit dat prog een trigger probeer te maken zegt ie dat de functie niet bestaat, in plaats van dat ie 'm ffies definieërt. Als ik dan vervolgens eerst zelf probeer de functie aan te maken, los van de trigger, moet ik opeens een return type opgeven. En Null slikt ie niet. En als ik dan een type opgeef zegt ie vervolgens dat ik NEW niet mag gebruiken. Iemand ideeën?

[JaQ]

xoror schreef op 04 July 2003 @ 15:14:
je wilt alleen packages omdat ze dan in het geheugen blijven hangen ???

ik dacht dat de algemene reden om packages te maken was dat je dan
funkties die 'bij elkaar horen' kan groeperen. met die schema's kan je iig vrij goed
oracle packages vertalen naar plpgsql. Daarnaast zal de opstart tijd van z'n stored proc minimaal zijn vergeleken met de tijd die de eigenlijke proc/udf nodig heeft.

heb je al eens een proc gemaakt dat zijn resultaten weer naar een volgende stuurd en deze weer terug naar de eerste?
Dat betekend dus 2 keer een procedure opstarten (tov package maar 1 keer). Als je nu een flinke bewerking wilt gaan uitvoeren met een stuk of 20 procs, dan kan jij wel bedenken wat de gevolgen zijn voor je machine

Geheugen is dus nog belangrijker dan groeperen (vooral als het om veel data en veel verschillende procedures / functies zijn).

[jochemd]

Type opaque.

[JaQ]

Verwijderd schreef op 04 July 2003 @ 15:25:
Hmmz, ik kom er niet uit met die triggers. Als 'k vanuit dat prog een trigger probeer te maken zegt ie dat de functie niet bestaat, in plaats van dat ie 'm ffies definieërt. Als ik dan vervolgens eerst zelf probeer de functie aan te maken, los van de trigger, moet ik opeens een return type opgeven. En Null slikt ie niet. En als ik dan een type opgeef zegt ie vervolgens dat ik NEW niet mag gebruiken. Iemand ideeën?

Zie http://www.postgresql.org...1&file=programmer-pl.html
en http://www.postgresql.org...file=plpgsql-trigger.html

Wel even de documentatie naslaan

[xoror]

opaque voor triggers tot en met 7.2 en 7.3 moet het wat anders zijn geloof TRIGGER oid
zie: http://www.postgresql.org...file=plpgsql-trigger.html

[jochemd]

DrFrankenstoner schreef op 04 July 2003 @ 15:27:

heb je al eens een proc gemaakt dat zijn resultaten weer naar een volgende stuurd en deze weer terug naar de eerste?
Dat betekend dus 2 keer een procedure opstarten (tov package maar 1 keer). Als je nu een flinke bewerking wilt gaan uitvoeren met een stuk of 20 procs, dan kan jij wel bedenken wat de gevolgen zijn voor je machine

Eigenlijk niet. Want een functie wordt maar 1 maal gecompileerd per connectie en alle query trees worden ook maar 1 keer bepaald. Dus zolang je niet voortdurend connecties opent en sluit, wat überhaupt al een probleem is voor de performance, zie ik het probleem niet zo.

[Verwijderd]

xoror schreef op 04 July 2003 @ 15:29:
opaque voor triggers tot en met 7.2 en 7.3 moet het wat anders zijn geloof TRIGGER oid
zie: http://www.postgresql.org...file=plpgsql-trigger.html

Hmmz, maar ik definieer dus een SQL functie, niet een PL/pgSQL functie. En voor SQL functies mag 't return type dus geen OPAQUE of TRIGGER zijn.

[JaQ]

jochemd schreef op 04 July 2003 @ 15:29:
[...]
Eigenlijk niet. Want een functie wordt maar 1 maal gecompileerd per connectie en alle query trees worden ook maar 1 keer bepaald. Dus zolang je niet voortdurend connecties opent en sluit, wat überhaupt al een probleem is voor de performance, zie ik het probleem niet zo.

Ik kan nu niet bewijzen dat deze bewering onwaar is, maar ik heb het toch echt altijd anders begrepen (terug de dev-docs in dus).

Maar goed, genoeg off-topic.


Wordt return type OPAQUE niet automagisch omgezet naar return type trigger indien dat nodig is? Volgens mij in ieder geval wel in 7.3.3

[xoror]

DrFrankenstoner schreef op 04 July 2003 @ 15:27:
[...]


heb je al eens een proc gemaakt dat zijn resultaten weer naar een volgende stuurd en deze weer terug naar de eerste?
Dat betekend dus 2 keer een procedure opstarten (tov package maar 1 keer). Als je nu een flinke bewerking wilt gaan uitvoeren met een stuk of 20 procs, dan kan jij wel bedenken wat de gevolgen zijn voor je machine

Geheugen is dus nog belangrijker dan groeperen (vooral als het om veel data en veel verschillende procedures / functies zijn).

dan is de opstart tijd van de proc nog steeds verwaarloosbaar tav de runtijd van de proc.
maar binnen 1 sessie worden die dingen wel herbruikt volgens mij.

[JaQ]

Verwijderd schreef op 04 juli 2003 @ 15:35:
[...]
Hmmz, maar ik definieer dus een SQL functie, niet een PL/pgSQL functie. En voor SQL functies mag 't return type dus geen OPAQUE of TRIGGER zijn.

Een sql-functie kent geen for each row. Die wil je dus eigenlijk al niet. een plpgsql functie helpt je meer in dit geval.
een plpgsql functie is niet zo veel spannender hoor...

pseudocode:

code:

create or replace function update_records_functie 
  ( eventuele_extra_parameter integer ) for each row
  returns trigger
  as '
 
declare
 pv_eventuele_extra_param alias for $1;
begin
  update tabelletje
  set       kolonaam = :NEW.kolomnaam + 1
  where  andere_kolomnaam = NEW.andere_kolomnaam
  and      weer_een_andere_kolomnaam = pv_eventuele_extra_param;
end;

  ' language plpgsql;

[Verwijderd]

DrFrankenstoner schreef op 04 juli 2003 @ 15:40:
[...]


Een sql-functie kent geen for each row. Die wil je dus eigenlijk al niet. een plpgsql functie helpt je meer in dit geval.
een plpgsql functie is niet zo veel spannender hoor...

pseudocode:

code:

create or replace function update_records_functie 
  ( eventuele_extra_parameter integer ) for each row
  returns trigger
  as '
 
declare
 pv_eventuele_extra_param alias for $1;
begin
  update tabelletje
  set       kolonaam = :NEW.kolomnaam + 1
  where  andere_kolomnaam = NEW.andere_kolomnaam
  and      weer_een_andere_kolomnaam = pv_eventuele_extra_param;
end;

  ' language plpgsql;

't probleem zit 'm er meer in dat m'n server geen PL/pgSQL ondersteunt .

[JaQ]

heb je volledige rechten? of mag je zelf geen talen installeren?

[Verwijderd]

DrFrankenstoner schreef op 04 July 2003 @ 15:46:
heb je volledige rechten? of mag je zelf geen talen installeren?

Servertje draait op m'n Linux server. Dus 'k kan 't wel installeren denk ik, als 'k wist hoe . Moe'k de server recompilen zeker?

[JaQ]

nope...

http://www.postgresql.org...&file=xplang-install.html

[Verwijderd]

DrFrankenstoner schreef op 04 July 2003 @ 15:52:
nope...

http://www.postgresql.org...&file=xplang-install.html

Okeej, 'k geloof dat 't gelukt is . Nu eens kijken hoe 'k die functie ga definiëren .

[Verwijderd]

Hmmz, ik geloof dat ik het enigzins aan de praat heb nu, maar 't werkt nog niet helemaal zoals 'k wil. Hier is m'n functie:

SQL:

BEGIN
     UPDATE locationdetails
     SET row = row + 1
     WHERE fk_location = NEW.fk_location
     AND "column" = NEW."column"
     AND row <= NEW.row
     AND EXISTS (SELECT 1
                 FROM location
                 WHERE stack = 'T'
                 AND location.location = NEW.fk_location);
     RETURN NEW;
END;

Dit werkt wel met 2 CD's op dezelfde locatie en dezelfde rij, maar als ik een derde CD toevoeg wordt de CD die op rij 1 stond verplaats naar rij 2, maar blijft de CD die op rij 2 stond op 2 staan. Maar die moet natuurlijk ook 1'tje opschuiven.

[JaQ]

Verwijderd schreef op 04 July 2003 @ 16:24:
Dit werkt wel met 2 CD's op dezelfde locatie en dezelfde rij, maar als ik een derde CD toevoeg wordt de CD die op rij 1 stond verplaats naar rij 2, maar blijft de CD die op rij 2 stond op 2 staan. Maar die moet natuurlijk ook 1'tje opschuiven.

Volgens mij is dat dus ook precies wat je in je functie vraagt. Wat je moet doen is je bestaande record-set mbv een cursor 1 voor 1 "downgraden". Kijk dus eens in de postgresql documentatie naar cursor en kijk of je daar wat mee kan.

Veel plezier en welkom in de wondere wereld die plpgsql heet.

[Verwijderd]

DrFrankenstoner schreef op 04 July 2003 @ 19:28:
[...]


Volgens mij is dat dus ook precies wat je in je functie vraagt. Wat je moet doen is je bestaande record-set mbv een cursor 1 voor 1 "downgraden". Kijk dus eens in de postgresql documentatie naar cursor en kijk of je daar wat mee kan.

Veel plezier en welkom in de wondere wereld die plpgsql heet.

Hmmz, 'k heb die cursors eens bekeken, maar ik kom er niet uit. Als 'k 't goed begrijp moet je in je DECLARE blok 't volgende zetten:

SQL:

ul CURSOR FOR <query>;
ld RECORD;

Vervolgens kun je dan in je code iets doen als:

SQL:

OPEN ul;
WHILE FOUND LOOP
    FETCH ul INTO ld;
    <doe iets leuks met ld>;
END LOOP;

Alleen werkt dat dus niet echt. Dus heb ik nog maar ffies verder gelezen in de documentatie, en toen kwam 'k met 't volgende idee:

SQL:

DECLARE
       ld RECORD;
BEGIN
       FOR ld IN SELECT * FROM locationdetails 
                      WHERE fk_location = NEW.fk_location AND "column" = NEW."column" 
                      AND row <= NEW.row LOOP
           UPDATE locationdetails SET row = ld.row + 1 
           WHERE fk_cd = ld.fk_cd AND fk_location = ld.fk_location;
       END LOOP;
       
       RETURN NEW;
END;

Maar dat levert dus 't resultaat op als wat ik al eerder had, dat 't allemaal 2 wordt in plaats van dat ie + 1 doet. Iemand nog ideeën?

[ Voor 7% gewijzigd door Verwijderd op 05-07-2003 17:26 . Reden: Verneukte layout ;) ]

[Verwijderd]

Ok als ik het goed begrijp heb CD's en lokaties en is "locationdetails" een combinatie daarvan die bijhoudt waar een CD op een bepaald moment zich bevindt. Je zou bij "locationdetails" een attribuut "tijd_geplaatst" kunnen toevoegen van het type timestamp met als default now().

In SQL code:
CREATE TABLE locationdetails
(.....
tijd_geplaatst timestamp DEFAULT now() NOT NULL,
....
);

En dan iedere keer dat als je een CD toevoegt bij een locatie de lijst opnieuw sorteren op "tijd_geplaatst" met een ORDER BY. Succes

[Verwijderd]

Verwijderd schreef op 05 July 2003 @ 17:46:
Ok als ik het goed begrijp heb CD's en lokaties en is "locationdetails" een combinatie daarvan die bijhoudt waar een CD op een bepaald moment zich bevindt. Je zou bij "locationdetails" een attribuut "tijd_geplaatst" kunnen toevoegen van het type timestamp met als default now().

In SQL code:
CREATE TABLE locationdetails
(.....
tijd_geplaatst timestamp DEFAULT now() NOT NULL,
....
);

En dan iedere keer dat als je een CD toevoegt bij een locatie de lijst opnieuw sorteren op "tijd_geplaatst" met een ORDER BY. Succes

Maar dat wil 'k dus niet. Want ik wil namelijk gewoon voor een CD op kunnen geven op welke rij hij zich in een stapel bevindt. Maar het wil nog wel eens gebeuren dat ik een CD ergens wil tussen voegen, of dat ik een CD boven op de stapel doe wat dus betekent dat alle andere CD's één rij op schuiven. Dan kan ik natuurlijk wel handmatig de boel gaan aanpassen, maar bij een stapel van 50 CD's moe'k dus 50 CD's aanpassen als ik er eentje bovenop leg .

[ACM]

Verwijderd schreef op 04 July 2003 @ 16:24:
Dit werkt wel met 2 CD's op dezelfde locatie en dezelfde rij, maar als ik een derde CD toevoeg wordt de CD die op rij 1 stond verplaats naar rij 2, maar blijft de CD die op rij 2 stond op 2 staan. Maar die moet natuurlijk ook 1'tje opschuiven.

Moet het niet gewoon >= ipv <= zijn
Je wilt de genen die hoger liggen aanpassen, niet de genen die lager liggen toch?

[ Voor 10% gewijzigd door ACM op 05-07-2003 18:35 ]

[Verwijderd]

ACM schreef op 05 July 2003 @ 18:34:
[...]

Moet het niet gewoon >= ipv <= zijn
Je wilt de genen die hoger liggen aanpassen, niet de genen die lager liggen toch?

Haha, inderdaad, helemaal niet aan gedacht. Overigens zijn het wel de CD's die lager liggen die moeten opschuiven. Maar hoe hoger het row veld, hoe lager ze liggen.

[Verwijderd]

Hmmz, nog even een vraagje? Ik heb nu de trigger zodanig ingesteld dat hij ook aangeroepen wordt op het moment dat er geupdate wordt. Maar dan krijg je dus een endless loop . Hoe zorg ik er voor dat hij alleen aangeroepen wordt voor het record dat geupdate wordt, en niet voor de updates die in de trigger uitgevoerd worden?