[ORACLE] Developer & Sequences

[Verwijderd]

Ik zit even vast met Oracle Developper.
Hoe kan ik er voor zorgen dat bij het creëeren van een nieuw record, automatisch een waarde wordt ingevuld als primary key, aan de hand van een sequence die ik met SQL aan een tabel heb toegevoegd?
Met SQL is het geen probleem, maar 't is de eerste keer dat ik met Developper werk.
Waar moet die .NEXTVAL gebruiken?

[justmental]

Het netste is om dit in een trigger op de betreffende tabel in de database te doen.

Dus before insert:
select sequence_naam.nextval
into :new.id
from dual;

[Verwijderd]

Dank u ^^

Moest ik nog eens vastzitten, mag ik dan nog vragen stellen ?

[Verwijderd]

Waarom werkt die niet met CURRVAL? of TO_NUMBER(seq_name.currval)+1 ?
Om die manier ontstaan er eigenlijk ongewilt gaps in mijn sequence.

[justmental]

Op maandag 13 mei 2002 16:58 schreef Satoshi het volgende:
Waarom werkt die niet met CURRVAL? of TO_NUMBER(seq_name.currval)+1 ?
Om die manier ontstaan er eigenlijk ongewilt gaps in mijn sequence.

Een sequence verhoogt zichzelf als je nextval selecteert.
Currval+1 is dus onzin.
Waarom zijn gaps een probleem?
En een sequence levert altijd opeenvolgende getallen tenzij je een cache waarde ingesteld hebt.

[Verwijderd]

Wel, als ik dat canvas open tijdens runtime, wordt die waarde ingevuld. Maar als de gebruiker niks wil toevoegen, en enkel raadplegen, genereert de sequence toch een nextval.
'k wou gewoon proberen dat te vermijden

[Verwijderd]

Als je gaps krijgt, gebruik je vast in je applicatie ergens een procedure die iets met die sequences doet. Als je een trigger inbouwt doe je het heel veilig, mooi alles op DB-niveau. Vrijwel nooit gaps dus.

[justmental]

Op maandag 13 mei 2002 17:15 schreef Satoshi het volgende:
Wel, als ik dat canvas open tijdens runtime, wordt die waarde ingevuld. Maar als de gebruiker niks wil toevoegen, en enkel raadplegen, genereert de sequence toch een nextval.
'k wou gewoon proberen dat te vermijden

Ehm, dan heb je toch wat anders gedaan dan ik bedoeld had
Ik doelde op een database trigger, dus in de database.
Deze genereert dan pas het volgende nummer bij de echte insert.

En gegenereerde id's zou ik niet laten zien in een applicatie.

[Verwijderd]

Dat bedoel ik dus, niet in je applicatie die Nextval opvragen, gewoon triggertje.

Wat heeft het trouwens voor zin om zo'n nummer te laten zien in je applicatie? Als het een ID o.i.d. is, dan hoeft de gebruiker dat helemaal niet te weten.

[Verwijderd]

Mja...

Ik had de trigger "WHEN-NEW-ITEM-INSTANCE" met volgende code:

code:

BEGIN
    SELECT SEQ_KLANT_KLANTNR.CURRVAL INTO :OTAKU_KLANT.KLANTNR FROM DUAL;
END;

Voor mijn part hebben de gebruikers er ook geen nut aan, maar als ze dat vragen ...

[justmental]

Op maandag 13 mei 2002 17:23 schreef Satoshi het volgende:
Mja...

Ik had de trigger "WHEN-NEW-ITEM-INSTANCE" met volgende code:

code:

BEGIN
    SELECT SEQ_KLANT_KLANTNR.CURRVAL INTO :OTAKU_KLANT.KLANTNR FROM DUAL;
END;

Voor mijn part hebben de gebruikers er ook geen nut aan, maar als ze dat vragen ...

Doe dat dan op z'n minst in de PRE-INSERT
Maar in de database is beter.
Kijk maar eens in je SQL manual bij CREATE TRIGGER.

[Verwijderd]

't zal voor mij toch nog experimenteren worden.
Op school zijn we dat eerder theoretisch

Ik had dat eerder met PRE_INSERT gedaan, maar dan zegt ie "FRM-40202: Field must be entered"

Arf... ik vind Oracle Developer toch een lastig programma, zeker als je daar iets mee moet maken voor mensen die enkel op een pc kunnne typen en er verder niks van af weten.

Dan zeggen ze nog dat dat user-friendly moet zijn. Maar als Oracle constant ping en van de FRM messages maakt, vraag ik me toch af hoe ik dat op een normale manier user-friendly kan maken

[Noork]

dan zet je in je properties toch gewoon required op NO, of je laat het nummer gewoon niet eens op je canvas zien

oh ja het is juist de bedoeling om makkelijke systemen met oracle te maken. en die FRM foutmeldingen kun je geloof ik wel afvangen en vervangen door eigen foutmeldingen. maar dat zijn dan geloof ik wel lastige triggers

[justmental]

Op maandag 13 mei 2002 17:48 schreef Satoshi het volgende:
Ik had dat eerder met PRE_INSERT gedaan, maar dan zegt ie "FRM-40202: Field must be entered"

Required van het veld afhalen, je hoort 'em toch niet te laten zien.

Arf... ik vind Oracle Developer toch een lastig programma, zeker als je daar iets mee moet maken voor mensen die enkel op een pc kunnne typen en er verder niks van af weten.

Eigenlijk is het nog te makkelijk gezien de troep die er veel te regelmatig mee gebouwd wordt.

Dan zeggen ze nog dat dat user-friendly moet zijn. Maar als Oracle constant ping en van de FRM messages maakt, vraag ik me toch af hoe ik dat op een normale manier user-friendly kan maken

Ach, het wordt toch uitgefaseerd binnenkort

[Noork]

ja gaan ze echt stoppen met oracle developer en desinger? wat gaat het dan worden? Jdeveloper of zoiets?

[Bergen]

[ORACLE] Developper & Sequences

Schrijf je dat echt met 2 p's??

[justmental]

Op maandag 13 mei 2002 17:54 schreef Noork het volgende:
ja gaan ze echt stoppen met oracle developer en desinger? wat gaat het dan worden? Jdeveloper of zoiets?

Designer is nog niet duidelijk, developer is een aflopende zaak.
Het is nu alleen nog maar Java wat de klok slaat.
Het is ook nog niet duidelijk of er ooit een migratie toolkit komt voor developer applicaties.

[Noork]

jammer, ik vond developer juist lekker om mee te werken, maar goed, das allemaal een beetje off-topic

[Verwijderd]

Op maandag 13 mei 2002 18:03 schreef GerbenW het volgende:

[..]

Schrijf je dat echt met 2 p's??

Nee, maar nu is het te laat om dat te veranderen

[JaQ]

als ik het me goed herinner zou je een pre-insert trigger moeten maken op het data-block.

Deze trigger zou iets moeten zeggen van:

begin

select <<sequencenaam>>.nextval
into <<blocknaam>>.<<kolomnaam>>
from dual;

end;


Al die "vieze" FRM-meldingen zijn vooralsnog goed voor je, daarmee leer je namelijk waar je je fouten in je applicatie maakt.. ;-)


/* offtopic

Het laatste wat ik gehoord heb is dat er nog 1 versie van designer komt en dat er dan ook met designer wordt gestopt. Het schijnt dat 70% van de designerlicenties in Nederland worden verkocht. Mondiaal dus niet zo'n interessant product voor Oracle

*/

[Verwijderd]

Ik ga daar morgen aan verder werken. 'k ben het beu.
Bedankt voor jullie tips

[Verwijderd]

offtopic:
't Zal ongetwijfeld Java worden. Als je ziet wat ze met Oracle Apps gemaakt hebben... ik duik er sinds vandaag in, maar zo op 't eerste gezicht ziet het er fantastisch uit. (moet nog verder browsen, maar dit is de eerste indruk )

Heb net Designer-project afgerond, was wel aardig, maar heel erg omslachtig allemaal. 't Mooie is, dat je voor de ontwikkelaar hele transparante applicaties kan maken. Ideaal voor onderhoud en dergelijke. Maar 't is geen RAD... helaas.

[justmental]

Op maandag 13 mei 2002 21:20 schreef TheGentleman het volgende:

offtopic:
't Zal ongetwijfeld Java worden. Als je ziet wat ze met Oracle Apps gemaakt hebben... ik duik er sinds vandaag in, maar zo op 't eerste gezicht ziet het er fantastisch uit. (moet nog verder browsen, maar dit is de eerste indruk )

Heb net Designer-project afgerond, was wel aardig, maar heel erg omslachtig allemaal. 't Mooie is, dat je voor de ontwikkelaar hele transparante applicaties kan maken. Ideaal voor onderhoud en dergelijke. Maar 't is geen RAD... helaas.

Ik ben nu een presentatie aan het maken (die ik morgen geef) over nieuwe ontwikkelingen bij Oracle.
De verandering van proprietary technologie naar open standaarden wordt een belangrijk punt daarin.

Apps was een drama, maar begint heel interessant te worden sinds de nieuwe architectuur in de laatste versie.

[Laszlo]

Je moet het je niet zo moeilijk maken . De manier is:
creeer tabel:
create table aap
( id number(
, name varchar2(200)
};

creeer sequence:
create sequence seq_aap;

Op het moment van inserten:
insert into aap (id, name)
values (seq_aap.nextval, 'Laszlo');


Klaar... Gaps in sequences zijn geen probleem. Sequences zijn bedoeld om unieke nummers te genereren, ook na een gap heb je een uniek nummer. Hier zijn natuurlijk wel uitzonderingen voor te verzinnnen (banksystemen), maar die zijn volgens mij niet echt van toepassing op jouw applicatie.

Succes!

[Verwijderd]

Nog even ter informatie, wellicht weet je het al, maar we praten over twee verschillende triggers. De "Pre-Insert", zowel als de "When-new-item-instance" trigger zitten in je Oracle applicatie en de triggers die wij je proberen aan te smeren zitten in de database zelf.

Hierdoor kun je onderscheid maken in de verschillende lagen van je 3-tier-model. Het soort triggers die ervoor zorgen dat een ID telkens wordt opgehoogd horen thuis in de database (onderste) laag. De Oracle-app-triggers in een hogere laag. Gebruik de hogere laag, (logische, middelste laag) om business rules te checken, zoals: record- of itemvalidatie (e-mailadres met @, begindatum <= einddatum, etc.).

Dit maakt je applicatie een stuk overzichtelijker, logischer, makkelijker te onderhouden

[Laszlo]

Op maandag 13 mei 2002 22:56 schreef TheGentleman het volgende:
Nog even ter informatie, wellicht weet je het al, maar we praten over twee verschillende triggers. De "Pre-Insert", zowel als de "When-new-item-instance" trigger zitten in je Oracle applicatie en de triggers die wij je proberen aan te smeren zitten in de database zelf.

Hierdoor kun je onderscheid maken in de verschillende lagen van je 3-tier-model. Het soort triggers die ervoor zorgen dat een ID telkens wordt opgehoogd horen thuis in de database (onderste) laag. De Oracle-app-triggers in een hogere laag. Gebruik de hogere laag, (logische, middelste laag) om business rules te checken, zoals: record- of itemvalidatie (e-mailadres met @, begindatum <= einddatum, etc.).

Dit maakt je applicatie een stuk overzichtelijker, logischer, makkelijker te onderhouden

Ik ben het hier niet zo mee eens. Validaties zou je ook goed in de database kunnen doen en dan de foutmelding naar een niveau hoger gooien. Het kan op alletwee de plaatsen (as en rdbms), zolang je maar consistent bent, maakt het qua overzichtelijkheid niet zoveel uit (vind ik).

Het voordeel van databasevalidatie is dat je echt alle data die je niet in de tabellen wil hebben kan uitsluiten, omdat je (zolang de je triggers niet disabled) dan zelfs in sqlplus je business rules handhaaft.

[Verwijderd]

Tuurlijk, alles kan, dat is mijn punt ook niet. Het verdient volgens mij wel de nodige aandacht als je applicaties bouwt. Het hele verhaal over gaps in de waardes van die sequence bewijst dat maar weer eens.

Ik zou daarom alleen de hoogstnodige business rules op databaseniveau vastleggen. Vooral wanneer je met meerdere applicaties op dezelfde database werkt. Dit is voornamelijk een ontwerpkwestie, een afspraak die je wilt maken met je mede-ontwikkelaars of klant, mijnsinziens.

Maar zoals ik al zei, alles kan, uiteraard.

[Laszlo]

Op dinsdag 14 mei 2002 08:47 schreef TheGentleman het volgende:
Tuurlijk, alles kan, dat is mijn punt ook niet. Het verdient volgens mij wel de nodige aandacht als je applicaties bouwt. Het hele verhaal over gaps in de waardes van die sequence bewijst dat maar weer eens.

Ik zou daarom alleen de hoogstnodige business rules op databaseniveau vastleggen. Vooral wanneer je met meerdere applicaties op dezelfde database werkt. Dit is voornamelijk een ontwerpkwestie, een afspraak die je wilt maken met je mede-ontwikkelaars of klant, mijnsinziens.

Maar zoals ik al zei, alles kan, uiteraard.

Een andere goede reden is als je uitwisselbaarheid van Databases zou willen, triggers werken niet overal

[Verwijderd]

Je moet toch eigenlijk niet willen uitwisselen met een database zonder triggers!

[80000]

justmental - maandag 13 mei 2002 18:05:

Designer is nog niet duidelijk, developer is een aflopende zaak.

Dat forms pleitte gaat, roepen ze al 5 jaar, maar het
is nog steeds niet gebeurt. Het gaat nog wel even heel lang duren, voordat dat weg is gezien de legacy code.

Niet dat ik een voorstander van forms ben, maar om de topic starter niet het gevoel te geven dat hij het voor niks doet.

[justmental]

Op woensdag 29 mei 2002 23:25 schreef 80000 het volgende:
justmental - maandag 13 mei 2002 18:05:
[..]

Dat forms pleitte gaat, roepen ze al 5 jaar, maar het
is nog steeds niet gebeurt. Het gaat nog wel even heel lang duren, voordat dat weg is gezien de legacy code.

Niet dat ik een voorstander van forms ben, maar om de topic starter niet het gevoel te geven dat hij het voor niks doet.

Dat roepen doen ze niet voor niks, het gaat eruit, maar omdat het zo'n grote installed user base heeft duurt het zo lang.
Nu is al wel duidelijk te merken dat er weinig effort in de evolutie van die tools gestoken wordt.
Ik waarschuw alleen maar omdat omtrent migratiemoglijkheden dus nog veel onduidelijk is.

[80000]

justmental - donderdag 30 mei 2002 00:37:

Dat roepen doen ze niet voor niks, het gaat eruit, maar omdat het zo'n grote installed user base heeft duurt het zo lang.
Nu is al wel duidelijk te merken dat er weinig effort in de evolutie van die tools gestoken wordt.
Ik waarschuw alleen maar omdat omtrent migratiemoglijkheden dus nog veel onduidelijk is.

Grote installed base, geen migratiemogelijkheden ... prachtig toch? Onze volgende Cobol. Als er nog eens een probleem is als Y2K probleem wordt er flink geld betaald voor Forms ontwikkelaars. Voor de topicstarter perfect, voor een bedrijf, tja wat minder perfect dan.

Het aantal ontwikkelaars aan Forms is zeker een stuk (significant) minder dan 5 jaar geleden, maar er is nog steeds een groep dat nieuwe patches (met functionaliteiten)oplevert. Deze groep blijft voorlopig ook nog wel bestaan.