Results 1 to 14 of 14

Thread: Hoe kan ik cached updates uitlezen?

  1. #1
    Registered User
    Join Date
    Jun 2002
    Location
    Zeist
    Posts
    5

    Hoe kan ik cached updates uitlezen?

    Hallo,

    Ik gebruik Delphi 4 en Interbase 5.6
    Ik onderhoud een systeem dat werkt met cached updates. Weet iemand hoe ik de SQL code die in cache staat kan uitlezen?


    Dank!
    J.

  2. #2
    Ik neem aan dat je cached updates in een Query component bedoelt? Dan staat het SQL statement in de SQL property van datzelfde component.
    Marcel

  3. #3
    Registered User
    Join Date
    Jun 2002
    Location
    Zeist
    Posts
    5
    Als het zo simpel was. Je hebt natuurlijk gelijk, maar dat lost mijn probleem niet op.
    Ik onderhoud een systeem, waarin op een bepaald moment RUNTIME een query (inclusief updateSQL) wordt aangemaakt binnen een bestaande datamodule. Dit gaat met een standaardroutine die door de rest van het systeem goed werkt.
    Per scherm wordt na OK / annuleren een routine uitgevoerd die voor de betreffende datamodule alle querycomponenten checkt op cached updates, en deze doorvoert in de database.
    Nu geeft deze betreffende query op het moment van doorvoeren een SQL syntax melding, ALLEEN na een delete. (token unknown, - line 4, char 23 ThemaCode.)
    Je bracht me wel op het idee, dat ik natuurlijk ook runtime via de debugger de updateSQL kon uitlezen. Daar lijkt niets mis mee.
    Nu zou ik toch heel graag weten wat precies in de cache staat voor deze specifieke update. Heb je nog een tip?

    In elk geval bedankt voor de reaktie!

    J.

  4. #4
    Dan snap ik niet precies wat je bedoelt. Ook al worden er runtime queries aangemaakt en gevuld (slecht ontwerp!) dan nog kun je toch de SQL statements uitlezen? En als je met cached updates werkt (eeh, nogmaals slecht design) zal er inderdaad een UpdateSQL gekoppeld moeten zijn, of wordt deze automatisch gegenereerd. Is er wel een keyfield aangegeven?
    Marcel

  5. #5
    Registered User
    Join Date
    Jun 2002
    Location
    Zeist
    Posts
    5
    Hallo Marcel,

    Oké, bottomline was, dat ik die !#$@ foutmelding er uit wilde hebben. En ik heb het gevonden!
    Inderdaad had ik de betreffende SQL-statements na jouw 1e antwoord al runtime bekeken.
    Maar daar zag ik op het eerste gezicht geen fout in, waardoor mijn vertrouwen in het goed doorgeven van de OLD_ÔǪ waarden nogal was gezakt. Daarom wilde ik graag precies terugzien wat het programma op dat moment aan Interbase doorgaf. Geen idee of dat überhaupt mogelijk is.

    Maar goed, in eerste instantie verkeerd gekeken, bleken er bij de delete- en modifySQL vreemde spaties in de velden OLD_enz. te staan. En dat kwam weer omdat deze spaties ook stonden in de string waarmee de keyvelden aan de functie CreateQuery werden doorgegeven
    (XCode;(spatie)YCode) moest zijn (XCode;YCode). Beginnersfout hèÔǪ
    ERG boeiend om de eerste stappen in Delphi als onderhoudsprogrammeur te doen..

    Nog even over een al dan niet slecht ontwerp: aan die discussie waag ik me nog maar niet. Ik vermoed dat het iets te maken heeft met de wens dat per scherm een annuleerfunctie moest worden ingebouwd. De ontwerper/bouwer zal dat hebben vertaald naar cached updates schat ik zo. En over dat runtime queries aanmaken: geen idee, de functie CreateQuery wordt van diverse plaatsen aangeroepen, misschien om het ontwikkelwerk te bekorten?
    Ik ga me binnenkort hierin verder verdiepen (cursus client/server), misschien heb je nog een tip over interessante artikelen over dit onderwerp?

    Dank alweer,
    J.

  6. #6
    Senior Member walterheck's Avatar
    Join Date
    Oct 2001
    Location
    Belo Horizonte, Brasil
    Posts
    4,212
    en aangezien ik me er graag aan waag... (niet de eerste keer)

    je kunt toch niet altijd voor elke verschillende query een verschillend tquery component gaan gebruiken? en in hoeverre vind je het creeeren en vullen op runtime fout? als ik een query heb voor bijvoorbeeld de customers tabel, en ik verander die iedere keer dat ik andere params nodig heb ofzo, vind je dat dan ook ffout (en waarom?). ik heb tegenwoordig al wel voor elke entiteit een query voor delete een voor select een voor update en een voor insert. dat vind ik meestal wel genoeg. ik hoor graag je mening (en die van anderen...)
    Nee, de Romeinen spraken geen ISO-8859-1 LATIN

  7. #7
    Als een query andere parameters krijgt is het inderdaad een andere query. Maar het is een grensgeval. Als het een query voor een rapport betreft waar als gevolg van selecties parameters bij en af moeten kan ik me voorstellen dat je dat runtime doet. Maar dat is dan ook de enige wijziging die runtime mag gebeuren.

    Als je bij mij bijvoorbeeld een factuurdatamodule zou zien dan zullen daar een stuk of 20 query componenten op staan. Bijvoorbeeld: openstaande bedragen, aanmaken van facturen, openstaande bedragen van een klant, noem maar op...

    Dat is de enige manier waarop ik mezelf kan garanderen dat het toevoegen van nieuwe functionaliteit (lees: nieuwe queries) niets breekt in de bestaande functionaliteit (lees: bestaande queries). Dus als ik iets nieuws toevoeg weet ik zeker dat ik de oude onderdelen niet hoef te testen. Als je je componenten voor verschillende toepassingen steeds aanpast kun je dat nooit garanderen.
    Marcel

  8. #8
    Senior Member walterheck's Avatar
    Join Date
    Oct 2001
    Location
    Belo Horizonte, Brasil
    Posts
    4,212
    maar als je nu bij de ene query 5 velden moet hebben en bij een volgende query 4 van dezelfde velden en een ander veld, dan toch een nieuwe query?
    Nee, de Romeinen spraken geen ISO-8859-1 LATIN

  9. #9
    Yep, als dat voor zou komen heb je daar blijkbaar een reden voor gehad. Als er reden genoeg was om nu opeens andere velden op te gaan vragen is dat ook reden genoeg om een nieuwe query aan te maken. Je moet trouwens wel, je hebt tenslotte meestal al de persistent fields aangemaakt dus kun je niet runtime opeens de velden gaan veranderen.
    Marcel

  10. #10
    Originally posted by walterheck
    en aangezien ik me er graag aan waag... (niet de eerste keer)

    je kunt toch niet altijd voor elke verschillende query een verschillend tquery component gaan gebruiken? en in hoeverre vind je het creeeren en vullen op runtime fout? als ik een query heb voor bijvoorbeeld de customers tabel, en ik verander die iedere keer dat ik andere params nodig heb ofzo, vind je dat dan ook ffout (en waarom?). ik heb tegenwoordig al wel voor elke entiteit een query voor delete een voor select een voor update en een voor insert. dat vind ik meestal wel genoeg. ik hoor graag je mening (en die van anderen...)
    Als ik het goed begrijp, hebben we het hier over het opzetten van een "onderhoudsarm" project.
    Waarom zou je geen algemeen scherm op kunnen zetten, met 2 Tquery's.
    q1 bevat "select omschrijving,statement from all_tables"
    q1 vult een combobox met omschrijvingen.
    de gebruiker kiest een omschrijving, waarmee het statement dat bij de omschrijving hoort in Q2.sql wordt gezet.
    DBgrid via via aan Q2 koppelen en je kunt alle tabellen onderhouden inclusief de tabel All_tabels en alles op runtime...
    Frits

  11. #11
    Senior Member walterheck's Avatar
    Join Date
    Oct 2001
    Location
    Belo Horizonte, Brasil
    Posts
    4,212
    dan heb je dus je query statements opgeslagen in je tabellen als ik het goed begrijp? ik weet niet of dat wel erg handig is.... maar ik weet ook geen reden waarom niet
    Nee, de Romeinen spraken geen ISO-8859-1 LATIN

  12. #12
    Misschien heb ik de verkeerde post geantwoord...
    Het ging om de opmerking van Marcel:

    Ook al worden er runtime queries aangemaakt en gevuld (slecht ontwerp!)

    Uit de context gerukt oke, maar daar heb ik moeite mee.

    Ik ben te veel programma's tegengekomen van anderen, die ik moest gaan onderhouden, waarbij met zulke zaken geen rekening was gehouden.

    "Onderhoudsarm" wil voor mij zeggen, met de minste moeite een goede oplossing bieden.
    Dus alleen een select statement toevoegen aan een DB table zonder de sourcs van delphi's aan te passen, dus veel minder testwerk en een gelukkige gebruiker omdat we zo snel (kunnen) reageren op zijn wens.
    Dus vind ik runtime queries een uitstekend ontwerp, mits je de juiste oplossing voor het probleem oplevert.
    Ik ben het met Marcel eens dat het maar zelden verdedigbaar is, om een runtime query hard te coderen, maar met persistent fields heb ik altijd overhoop gelegen.

    Maar misschien is dit "off topic" en zou ik een nieuwe thread moeten starten over
    "Ontwerp beslissingen".
    Frits

  13. #13
    Senior Member walterheck's Avatar
    Join Date
    Oct 2001
    Location
    Belo Horizonte, Brasil
    Posts
    4,212
    off-topic? wat was dat ook alweer?

    toch lijkt het me geen geweldige oplossing om dat soort dingen in een db te zetten. Ik heb me ondertussen wel redelijk laten overtuigen door een zeker e webmaster. alleen niet op een klein punt: zoeken.
    in een zoekscherm wil je de klant op meerdere dingen kunnen laten zoeken. moet je dan voor elk van die mogelijkheden een aparte query maken? dta worden er wel veel als er bijvoorbeeld 4 zoekvelden zijn...
    Nee, de Romeinen spraken geen ISO-8859-1 LATIN

  14. #14
    Nee, dat is inderdaad de welbekende uitzondering op de regel. Is ook geen probleem want de data veranderd dan niet, alleen de parameters.
    Marcel

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. Replies: 12
    Last Post: 10-May-06, 23:19
  2. Replies: 7
    Last Post: 04-Jun-04, 21:48
  3. Replies: 2
    Last Post: 13-Mar-04, 01:27
  4. Hoe kan ik registreren voor opstarten?
    By kuntao in forum Algemeen
    Replies: 5
    Last Post: 31-Aug-01, 09:52

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
  •