Page 3 of 8 FirstFirst 1 2 3 4 5 ... LastLast
Results 31 to 45 of 107

Thread: Database keuze na Paradox

  1. #31
    In principe maakt de keuze van een RDBMS voor de bouw van een applicatie niet veel uit.
    Meestal is de programmatie van Paradox verschillend. De table-achtige syntax :

    Delphi Code:
    1. Table.First;
    2. While not Tabel.Eof do
    3. begin
    4.   if FieldByName('Status').Asstring = 'BE' then
    5.   begin
    6.      Table.Edit;
    7.      FieldByName('Einde').AsBoolean:= true;
    8.      Table.Post;
    9.   end;
    10.   Table.Next;
    11. end;

    De SQL-achtige syntax:

    Delphi Code:
    1. With Query do
    2. begin
    3.   SQL.Text:= 'UPDATE Table SET Einde = 1 WHERE STATUS = ''BE''';
    4.   ExecSQL;
    5. end;

    Beide zijn nu echt geen schoolvoorbeelden, maar wat ik bedoel is dat de programmastructuur en de manier van programmeren nogal verschilt. Het is meer dan enkel wat Table-componentjes vervangen door Query-spullen, soms is het gewoon carrément de boel herschrijven. Enfin, zo heb ik het toch moeten doen.
    Last edited by Handsaeme; 23-Jan-09 at 12:49.

  2. #32
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,830
    @Handsaeme, begrijp ik het goed dat je in je post juist wél de verschillen tracht uit te leggen van de keuze tussen het ene en een ander RDBMS ?

    Mijn begrip van een RDBMS is Oracle, MS SQL Server, FireBird en noem ze maar op, geen desktopdatabase zoals Paradox. Dus ja, tussen Paradox en een RDBMS heb je wél veel verschillen. Als je je applicatie eenmaal zover hebt dat het op een RDBMS kan draaien, dan maakt de keuze RDBMS niet zo heel veel meer uit.

    Overigens bevat mijn code nog steeds m.n. jouw 1e voorbeeld, alleen is de Table nu een ClientDataSet. Jouw 2e voorbeeld laat ik vooral de DataSetProvider voor me doen. Ik bepaal alleen de query's om de juiste data op te halen.
    Last edited by Hans Brenkman; 23-Jan-09 at 13:35. Reason: Aanvulling op code voorbeelden
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  3. #33
    Wat is bedoelde is het volgende:

    Je hebt table-achtige databases zoals Paradox, DBF, XML (als ik dit ook kan noemen), .... en je hebt RDBMS-sen zoals Firebird en Oracle. Tussen die twee types is er enorm veel verschil en het is moeilijk om iets iets te schrijven voro het ene zonder consequenties te hebben voor het andere.

    Een keer je je applicatie draaiende hebt voor één bepaalde RDBMS, dan gaat het overschakelen naar een andere wel heel wat vlotter ( je hebt altijd van die eigenaardigheden, maar dat laat ik buiten beschouwing ). Ik bedoel: iedereen kan rijden in een auto, maar twee auto's van een verschillend merk zijn ook anders.

    Het voordeel van Firebird in combinatie met Delphi is dat Firebird ( en Interbase ) in combinatie met Delphi wel wat te appreciëren extra's hebben.

  4. #34
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    9,949
    Quote Originally Posted by Handsaeme View Post
    Ik heb deze keuze vroeger weggelaten omdat er geen replicatie-mogelijkheden of linkedserver-mogelijkheden waren en je verplicht moest werken met Applicatieve replicatie.
    Dan moet je PostgreSQL wel opnemen.

  5. #35
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    9,949
    Quote Originally Posted by Wok View Post
    Dat ben ik niet met je eens, kijk maar eens op de website
    in het midden aan de rechterkant daar staat :

    "PostgreSQL is free. Please support our work by making a donation. "
    Een vrijwillige donatie vragen heeft niets met licentie kosten te maken.

  6. #36
    Tussen die twee types is er enorm veel verschil en het is moeilijk om iets iets te schrijven voro het ene zonder consequenties te hebben voor het andere.
    Ik snap je uitleg nog steeds niet helemaal.

    Technisch zijn ze inderdaad wezenlijk verschillend.

    Maar net als Hans heb ik jouw 1e voorbeeld ook in mijn code zitten, terwijl daar toch echt een rdbms achter ligt, vaak zelfs met middleware.

    Waar je volgens mij naar toe wilt is dat je bij een filebased database zoals Paradox en dbase in principe de hele tabel beschikbaar hebt. Via een index of een filter trek je dan data uit die hele tabel.

    Gebruik je een rdbms dan gebruik je bij de meeste SQL om data op te halen. Die queries leveren je een selectie uit je database op. Zou je op die SQL database een select * from table doen zonder where, dan heb je in feite weer hetzelfde als bij de filebased databases.

  7. #37
    Wat ik bedoel is het volgende: Toen ik in een vorig leven de applicatie van BDE/Paradox naar BDE/SQL Server overzette, dacht ik een tijger in mijn tank te hebben, maar in werkelijkheid liep mijn applicatie gewoon vast omdat heel de applicatie op de Paradox-manier geschreven was: je tabel binnenhalen en een filter er op zetten en daar had ik geen rekening mee gehouden.

    Alle voorbeeld-1 code is toen overgezet geweest naar voorbeeld-2 code ( met parameters uiteraard )

  8. #38
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    9,949
    Ik denk dat Benno probeert te zeggen dat dit te voorkomen is door beide manieren een beetje op een afstand van de bulk van je code te houden. Dan kan je makkelijker switchen.

  9. #39
    En niet te vergeten DBISAM van Elevatesoft, kan zowel file based, dus op een share draaien als multi-user of als 'echte' database server op bijvoorbeeld Windows 2003 server. Snel, stabiel, portabel, met simpel aanpassing van file based naar database server, redelijk goedkoop, ondersteuning van SQL92 enz.

  10. #40
    Quote Originally Posted by Hans Brenkman View Post
    ...je zult vooral van rechtstreeks in de tabellen data bewerken nu moeten kijken naar bijv. de ClientDataSet en je data met SQL ophalen ed.
    Gelukkig heb ik bijna alle databewerking al via SQL lopen i.p.v. rechtstreeks met (bijv.) een TTable component, dus dat probleem zal voor mij waarschijnlijk reuze meevallen. Die verandering heb ik lang geleden al gemaakt omdat ik dacht/hoopte dat het de stabiliteit ten goede zou komen in een multi user omgeving. Het heeft zeker geholpen, maar niet voldoende.

    Ik zie persoonlijk meer op tegen al die rare (outer) join -statements, datumformaten, blobs/memovelden, etc. die moeten worden aangepast, en ook het maken van back-ups (vanuit mijn programma), etc. Maar, ik denk dat ik de komende tijd aan de slag ga met een zoektocht naar goede voorbeelden met Firebird zodat ik uiteindelijk kan overstappen. Ik ben het gedoe met corrupte Paradox tabellen helemaal zat.

  11. #41
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,830
    Ik heb bij de overgang van Paradox naar Oracle (en dat is dus voor een ander RDBMS waarschijnlijk niet veel anders) een kleine tool gebouwd die de Paradox files inlas, daarop een integriteitscontrole uitvoerde, een controle op memovelden > 4000 bytes deed en vervolgens SQL insert scripts bouwde voor Oracle.

    M.n. memovelden > 4000 bytes kreeg ik niet zo gemakkelijk naar een andere database. Hiervoor moest ik buiten de SQL scripts om iets maken om dit via een MemoryStream in te lezen. Het waren toen maar 4 records, dus heb ik dat toen handmatig met knippen en plakken gedaan. Bij een groter aantal zul je dus eerst je database moeten vullen en later dit aan moeten vullen.

    In een andere app gebruiken we dit nu dagelijks, bij een SQL insert > 4000 bytes (XML) gaat het via een ClientDataSet en een MemoryStream.

    Wat je backup betreft; dit zou ik niet in je app regelen. Dat gaat ook bijna niet want een goede backup kun je (grofweg) alleen maken als niemand in de database ingelogd is.

    Oracle kan dat bijv. wel, omdat bij een hot backup (als je database bijv. 24x7 "up" moet zijn) Oracle elke tablespace (datafiles) afzonderlijk één voor één offline kan halen om te backuppen, daarna de intussen ontstane mutaties via redologs of zelfs archivelog files bijwerkt. Om te restoren heb je dus ????k je archivelog files nodig.

    Hoe het met MS SQL Server zit weet ik niet exact (ik hou me meer met Oracle bezig), daar maken we via een job een automatische offline backup van, er is ook een transactionlog. Dus zal ook hier wel een soort gelijke restore kunnen plaatsvinden als je een hot-backup neemt (ik neem aan dat dat met MS SQL Server mogelijk is, maar wij doen het niet).

    Voor FireBird geldt hetzelfde: een goede backup kan alleen gemaakt worden als de FireBird server niet draait. Wel heb ik in een standalone app waar ik FireBird embedded gebruik (maar dat is voor meer dan 1 gebruiker geen optie) in de app een backup en restore gemaakt. Hiervoor gebruik ik de componenten van Unified Interbase (wederom gratis ).
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  12. #42
    Ik hoop dat ik er over een aantal maanden om kan lachen... Op dit moment zie ik er eerlijk gezegd best tegenop om een stabiele applicatie met een minder stabiele database te moeten omzetten naar een ander database platform. Maar het doel (meer stabiliteit) heiligt de middelen (nachtjes zonder slaap en veel SQL code)...

    De database hoeft zeker niet 24x7 online te zijn. Ik heb het backup mechanisme destijds in mijn programma ingebouwd zodat er elke ochtend, zodra mijn programma wordt opgestart, automatisch eerst een volledige backup wordt gemaakt van de database bestanden. Een aantal van mijn klanten heeft de boel zo ingesteld dat de backup ergens op dezelfde schijf (als het programma en de productiedatabase) komt te staan, maar gelukkig zijn de meeste klanten inmiddels zover dat ze de backup op bijvoorbeeld een memory stick o.i.d. laten schrijven. Als het in Firebird niet mogelijk is om een 'hot' backup te maken, dan maar buiten de applicatie om... Belangrijker is DAT er een backup wordt gemaakt.
    Last edited by roosiedb; 23-Jan-09 at 21:14.

  13. #43
    Ik zie niet in waarom het niet zou mogelijk zijn om een backup te maken van je database, dit is in principe altijd mogelijk, zelfs al is je database aan het werk. Sommige databases zijn 24/24u, 7d/week en 52 weken per jaar actief en daar lukt backuppen ook.

    Wat je in principe doet is on-line de gegevens van de database gaan wegschrijven in een afzonderlijk bestand, dit noemt men 'dumpen'. Dit doe je het best enige tijd voor het nemen van de backup zodat de gegevens worden meegenomen op tape.

    In een 'stil moment' kunnen een aantal acties gebeuren, ik weet niet of Firebird deze allemaal ondersteunt of ze wel nodig zijn, maar op SQL Server gebeurt dit:
    1. Het nemen van statistiek-tabellen
    2. De integriteitschecks op de database ( het checken van alle tabellen op fouten)
    3. Het onderhoud op het systeem zoals het herindexeren van de indexen. Deze zijn niet noodzakelijk voor de werking van de server, maar zorgt er voor dat het systeem sneller gaat werken en de database wat minder plaats inneemt.
    4. Het dumpen van de database in een backupbestand
    5. Het dumpen van de transaction log in een backupbestand
    6. Het nemen van een backup op tape.

    Als je de instructies kent is punt 1-5 maar een half uurtje werk, dus heel wat minder dan dit applicatief te gaan regelen.
    De verbazing begint waar de kennis ophoudt

  14. #44
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,830
    Quote Originally Posted by roosiedb View Post
    Ik hoop dat ik er over een aantal maanden om kan lachen...
    Wedden ?

    Quote Originally Posted by roosiedb View Post
    Ik heb het backup mechanisme destijds in mijn programma ingebouwd zodat er elke ochtend, zodra mijn programma wordt opgestart, automatisch eerst een volledige backup wordt gemaakt van de database bestanden.
    Alleen dan toch de gebruiker die het eerste de app op die dag opstart ?

    Quote Originally Posted by roosiedb View Post
    Belangrijker is DAT er een backup wordt gemaakt.
    Uiteraard
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  15. #45
    Quote Originally Posted by Hans Brenkman View Post
    Alleen dan toch de gebruiker die het eerste de app op die dag opstart ?
    Jazeker. In de database wordt namelijk ook een record weggeschreven met de datum/tijd waarop de backup is gemaakt, zodat er (tenzij anders ingesteld) slechts 1 keer per dag een volledige backup wordt gemaakt.

Page 3 of 8 FirstFirst 1 2 3 4 5 ... LastLast

Thread Information

Users Browsing this Thread

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

Tags for this Thread

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
  •