Results 1 to 10 of 10

Thread: Firebird versie 3

  1. #1
    Senior Member ErikB's Avatar
    Join Date
    Aug 2010
    Location
    Biddinghuizen
    Posts
    509

    Firebird versie 3

    Op de site van Firebird las ik dat versie 2.5.9 nu beschikbaar is, en dat na deze er geen versie 2.xxxx meer gemaakt zal worden.
    Overgaan naar versie 3 wordt aanbevolen.

    Maar... wat zijn jullie ervaringen betreffende versie 3, is het een verstandige stap (draaien nu op 2.5.8) ?
    Kom ik valkuilen tegen bij het overgaan naar 3 ?

    graag hoor ik er meer over
    Erik

  2. #2
    Ik draai bij de meeste klanten nog met 2.5. Zelfs nog op 2.1 en een enkele op 2.0.
    Ik voorzie niet dat die binnen een (paar) jaar overgezet worden naar 3.

    Zelf draai ik op één server (zonder problemen) op 3.0 (naast mijn development computer op 2.5.8).

    Valkuilen bij 3. Tsja, dat is een kwestie van uittesten.
    Je zou 3.0 op je eigen computer kunnen installeren.
    Ook is het mogelijk 3.0 als embedded in een aparte directory te zetten met een testversie van je programma om het op die manier te testen.

    Handig om de Release notes van 3.0 even door te nemen.

    Ik denk alleen dat je bij een migratie van een bestaande database even wat werk hebt met backuppen op 2.5 en dan restoren op 3.0 maar voor de rest denk ik dat het mee zal vallen.

  3. #3
    Senior Member ErikB's Avatar
    Join Date
    Aug 2010
    Location
    Biddinghuizen
    Posts
    509
    testen zal ik zeker doen, natuurlijk. Maar als er gebruikers zijn die op voorhand al belangrijke opmerkingen hebben ...
    de release notes is gelukkig (!) maar een paar pagina's, ga ze wel doorlezen.
    iig dank voor je reply
    Erik

  4. #4
    Werk nu een tijdje met 3.0, ben geen problemen tegengekomen. Grote pluspunten vind ik dat nu (eindelijk) ook Booleans worden ondersteund, en InternalFunctions (welke je trouwens ook vanuit Extern (dus je applicatie) kunt aanroepen).
    Add one binary to 1, and suddenly
    you end up with 10.

  5. #5
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    ...en InternalFunctions (welke je trouwens ook vanuit Extern (dus je applicatie) kunt aanroepen).
    Nieuwsgierig! Example-code?

    Ik gebruik Firebird 3 embedded al een jaar. Idd lekker: booleans.

  6. #6
    Internal Function is in principe gewoon een StoredProc, maar dan met 1 resultaat.
    Indien geen input-parameter, dan aanroepen met gesloten haakjes ()

    Dus deze roep je (in PSQL) bijv. aan met: if FCheckIfAllowedCustomer(1) then

    SQL Code:
    1. CREATE OR ALTER FUNCTION FCHECKIFALLOWEDCUSTOMER(
    2.     nID Integer)
    3. returns BOOLEAN
    4. AS
    5. declare variable nCounter Integer;
    6. begin
    7.   SELECT Count(ID) FROM Customers
    8.   WHERE ID = :nID AND IsAllowedForEdit=True
    9.   INTO :nCounter;
    10.  
    11.   IF (:nCounter = 0) then
    12.     RETURN False;
    13.   else
    14.     RETURN True;
    15. end


    Deze roep je (in PSQL) aan met: BooleanVariable = FCheckIfRunningAbo(); (of if FCHeckIfRunningAbo() then)

    SQL Code:
    1. CREATE OR ALTER FUNCTION FCHECKIFRUNNINGABO
    2. returns BOOLEAN
    3. AS
    4. declare variable DDATUM date;
    5. begin
    6.   execute statement 'select BeeindigdPerDatum from Customers where ID = 1'
    7.   ON external DATA source 'MyDatabaseserver:MyDatabase'
    8.   AS user 'username' password 'password'
    9.   INTO :dDatum;
    10.  
    11.   IF (:dDatum IS NOT NULL) then
    12.     RETURN False;
    13.   else
    14.     RETURN True;
    15. end
    In Delphi: FDStoredProc of FDQuery-component in Datamodule, laten verwijzen naar aangemaakte InternalFunction (daarom beginnen deze bij mij in de naam altijd met F)
    Vervolgens standaard opvragen:

    Delphi Code:
    1. ProjectsDataModule.FDStoredProc1.ParamByName('nID').Value := 1;
    2. ProjectsDataModule.FDStoredProc1.ExecProc;
    3. Showmessage(ProjectsDataModule.FDStoredProc1.ParamByName('Result').AsString);

    En deze InternalFunction is gedefinieerd als:
    SQL Code:
    1. CREATE OR ALTER FUNCTION Fname(nid integer)
    2. returns varchar(100)
    3. AS
    4. declare variable Result varchar(100);
    5. begin
    6.   SELECT firstname FROM users WHERE id = :nID INTO :Result;
    7.   RETURN :Result;
    8. end

    Maar deze InternalFunctions kun je dus ook gewoon in je sql-statements opnemen (select naam, fname(1), bla, bla from bla,bla where etc.)

    Uitgebreid voorbeeldje, maar dan heb je ook wat :-)
    Last edited by GolezTrol; 31-Jul-19 at 13:48.
    Add one binary to 1, and suddenly
    you end up with 10.

  7. #7
    je krijgt zo wel een database die op termijn niet of moeilijk te onderhouden is en nog lastiger te debuggen.

    Je ziet juist een trent om zoveel mogelijk logica weg te halen uit de database en te verplaatsen naar een middleware laag.

    Maar zoals met alle ontwikkelingen, het is een keuze.

  8. #8
    Nou, niet persé. Ik werk uitsluitend met StoredProcs (en dus nu ook InternalFunctions), in de applicaties komen nergens Queries voor. Validaties worden consequent uitgevoerd in de database. Maxlen/MinMax van Edits ed. wordt bepaald door de velddefinitie/uitvoer van de opgevraagde data. Append/Update/Delete-acties gaan als parameters naar een StoredProc, die moet maar bepalen of, en zo ja hoe of wat er gedaan moet worden. Resultaat-param geeft aan de applicatie het Result van de gewenste actie door.
    Datasnapserver erbij, draaien maar. Ben nu bijv. voor een klant een Firemonkey-app erbij aan het maken, ontwikkeltijd is meer dan gehalveerd, tijd zit voornamelijk in het definieeren van de GUI.
    Add one binary to 1, and suddenly
    you end up with 10.

  9. #9
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Thanks! Kan soms handig zijn idd lijkt me. Ik zal eens kijken of ik het ergens kan gebruiken in mijn eigen progje.
    Ik ben overigens ook iemand die vindt dat logica in een database zoveel mogelijk beperkt moet zijn.

  10. #10
    Nou, niet persé. Ik werk uitsluitend met StoredProcs (en dus nu ook InternalFunctions), in de applicaties komen nergens Queries voor. Validaties worden consequent uitgevoerd in de database. Maxlen/MinMax van Edits ed. wordt bepaald door de velddefinitie/uitvoer van de opgevraagde data. Append/Update/Delete-acties gaan als parameters naar een StoredProc, die moet maar bepalen of, en zo ja hoe of wat er gedaan moet worden. Resultaat-param geeft aan de applicatie het Result van de gewenste actie door.
    Dat is nu precies wat je in je middleware oplost.

    Jij kiest ervoor om je database je businesslaag te laten zijn. Verder prima als dat je bevalt, maar je oplossing is er minder schaalbaar door, je zit 100% vast aan die database en zoals ik al eerder schreef is mijn ervaring dat het onderhoud op termijn moeilijker wordt.

    Maar goed je hebt kennelijk gegronde redenen waarom je hiervoor kiest, veel succes.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •