[Delphi] Query koppelen aan twee datasources

[Tomatoman]

Ik probeer een query bouwen die gegevens haalt uit twee datasources. SQL property van de TQuery moet zoiets zijn als:

code:

SELECT O.CustNo, O.OrderNo, C.Company
FROM Orders O, Customer C
WHERE O.CustNo = C.CustNo

Hoe kan ik dit doen?

[Creepy]

gebruik een tdatabase om je database te openen, en ken de tdatabase.databasename toe aan de tquery.databasename.

Zo kan je tquery gebruik maken van elke tabel in je database.

[whoami]

Ik snap uw probleem niet.
Meestal koppel je een datasource aan een query zodat je de gegevens die uw query returned aan data-aware controls kunt hangen. (Je kunt ook wel de omgekeerde weg bewandelen, maar ik denk niet dat het dat is wat je bedoeld).

Je wilt dus gewoon gegevens uit uw databank halen en die gegevens komen uit 2 verschillende tabellen? Dan geeft Creepy al de oplossing gegeven, maar wat bedoel je nu met die datasources?

[Tomatoman]

In mijn locale database heb ik twee tabellen, Orders en Customer. Als componenten heb ik twee ingewikkelde TQuery's, waarvan de ene (QueryO) zijn gegevens haalt uit Orders en de andere uit Customer (QueryC). De derde (QuerySamen) moet zijn gegevens halen uit die eerste twee querys en dat lukt dus niet.

Omdat QueryO en QueryC nogal veel rekenwerk vergen, wil ik ze in aparte threads zetten, zodat ze parallel uitgevoerd kunnen worden . Daarom heb ik de drie query's ook niet gecombineerd tot één ingewikkelde query. Maar voordat ik aparte threads ga bouwen, wil ik eerst het principe van die drie samenwerkende query's werkend krijgen.

QuerySamen kan zijn gegevens trouwens probleemloos halen uit QueryO óf QueryQ door QuerySamen.DataSource daarop in te stellen. Maar uit beide tegelijk lukt niet.

Is mijn probleem duidelijk?

[Creepy]

Als je die twee tabellen lokaal hebt staan, ga je echt geen (of nauwelijks)performance winst halen door 2 queries parallel te laten lopen.

Stel gewoon 1 query op allebei de tabellen om precies de info op te halen die jij wilt.

Als dit echt te traag gaat, ga dan eens kijken naar indexen, en de opbouw van je query. Meestal kan je hiermee nog aardig wat winst halen (goede indexen zijn voor de opvraag snelheid erg belangrijk.. en natuurlijk je query zo maken, dat er zoveel mogelijk aan het begin wordt uitgefilterd)

Over wat voor soort database praten we hiero eigenlijk? En wat staat er allemaal in je tabellen als het opvragen zo traag gaat?

[Tomatoman]

Het gaat om een Access 97 database waarin 800.000 bestelregels staan. De querynamen die ik noemde, heb ik even verzonnen om het niet te ingewikkeld te maken. Op dit moment duurt het in Access vijf tot tien minuten voordat de langzaamste query klaar is . Een klein beetje snelheidswinst is hier al de moeite waard.

[Creepy]

en wat voor queries zijn het dan?? Een selectie van een paar records zou alsnog snel moeten gaan (mits goede index etc.).

Als je queries gaat stellen voor statistieken, totalen, etc. kan het lang gaan duren ja. Misschien is het dan een idee om bepaalde informatie dubbel, of alvast berekend, op te slaan in de DB, zodat dit het opvragen een stuk versneld. Als die info eenmaal is gegenereerd, is het meestal weinig werk, om deze extra info kloppend te houden. Ok, het is dan niet optimaal meer genormaliseerd, maar als je een flinke snelheidswinst kan boeken op deze manier.. waarom niet..

Welke info je alvast berekend wilt opslaan, is uiteraard afhankelijk van de queries die je stelt.

[Tomatoman]

Een aantal query's kan ik in Delphi direct overnemen uit Access, waar ik ze heb getest. Onderstaande query is afhankelijk van drie andere query's. Gezien de complexiteit zul je begrijpen dat ik liever niet meer in dergelijke query's klooi en ze 1 op 1 wil migreren naar TQuery componenten in Delphi. Maar dat lukt voor onderstaande query alleen als ik met de TQuery in Delphi datasets kan lezen uit diverse andere TQuery's tegelijk. En dat is nou juist het probleem: kan dat?

code:

SELECT tblDivisies.DivisieAfk, qryBestellingen.Kostenplaats, Sum(qryEURwaarde.EURwaarde) AS EURwaarde,
  qryBestellingen.Leveranciersnr, tblLeveranciers.LevNaam, tblLeveranciers.LevNaamToevoeging,
  Count(qryEURwaarde.EURwaarde) AS AantalBest, tblKostenplaatsen.Omschrijving AS KsnplaatsOmschrijving
FROM tblDivisies
  INNER JOIN (((((qryBestellingen INNER JOIN qryEURwaarde ON qryBestellingen.ID = qryEURwaarde.ID)
        INNER JOIN qryKsnplaatsSelectie ON qryBestellingen.Kostenplaats = qryKsnplaatsSelectie.Kostenplaats)
      INNER JOIN tblKostenplaatsen ON qryKsnplaatsSelectie.Kostenplaats = tblKostenplaatsen.Kostenplaats)
    INNER JOIN qryDivisieSelectie ON tblKostenplaatsen.DivisieID = qryDivisieSelectie.DivisieID)
    LEFT JOIN tblLeveranciers ON qryBestellingen.Leveranciersnr = tblLeveranciers.LevNr)
  ON tblDivisies.DivisieID = tblKostenplaatsen.DivisieID
GROUP BY tblDivisies.DivisieAfk, qryBestellingen.Kostenplaats, qryBestellingen.Leveranciersnr,
  tblLeveranciers.LevNaam, tblLeveranciers.LevNaamToevoeging, tblKostenplaatsen.Omschrijving
ORDER BY tblDivisies.DivisieAfk, qryBestellingen.Kostenplaats, Sum(qryEURwaarde.EURwaarde) DESC;

[Verwijderd]

Wat een rotquery zeg.. sorry dat ik het zeg, maar als dit het resultaat is van je eigen werk.. begin overnieuw.

Dit soort queries zijn gewoon niet te onderhouden.

Ik denk niet dat een tquery component z'n data uit 2 datasources kan halen (althans niet zoals jij het omschrijft).

Wat je wel kunt doen is de beide queries in de .sql van je 'uiteindelijke' querie stoppen, maar mooier wordt het er allemaal niet van.

Overigens: MS Access? Moet dat ook de database worden? Doe dat jezelf alsjeblieft niet aan. Wil je het perse wel zo doen, vermijdt dan iig. autoinc velden. Gebruik je die wel dan is binnen een maand de integriteit van je database naar de kloten (sorry dat ik het zeg, maar het is wel zo )


Overigens.. je kunt dit wel vereenvoudigen door substitutie. Je hebt 2 werkende queries welke je uiteindelijk wilt samenvoegen tot 1 'monster-query'. Noem de 1e even A en de 2e even B. Maak daarna je query zoals je 'm wilt hebben. Dan als laatste A en B weer vervangen door de resp. queries.

Maar eerlijk gezegd zou ik er niet aan beginnen. Je krijgt dan nl. 1 totaal niet-onderhoudbare query. Dat probleem zie je nu al.

[Tomatoman]

Het zijn inderdaad klotequery's, met dank aan Access dat ze zo genereert. Natuurlijk moet de applicatie in Delphi straks niet aan Access hangen, want dan blijft de performance bagger met die 800.000 records.

Maar voordat ik zaken rigoreus ga omgooien, wil ik zeker weten dat het principe met die aan elkaar gekoppelde query's werkt. Met één query als datasource voor de tweede werkt het natuurlijk, want dat is het principe waarmee je met TQuery's master/detail-relaties maakt. Maar twee query's als gezamenlijke datasource?

[Creepy]

2 queries als 1 gezamelijke datasource gaat niet.
Maar dit is vast wel weer na te doen m.b.v. sub selects.


dus iets ala:

code:

select * from blaat where
   b.id = (select id from bla where dinges='goh') and
   b2.id = (select id from bla2 where dinges='goh')

i.p.v.

code:

select * from blaat b where
   b.id=query1.id and
   b.id2=query2.id

Als uit die 2 queries, dezelfde velden komen, dan kan je die twee queries m.b.v. een union samenvoegen tot 1, maar ik geloof niet dat dat hier het geval is....

Is het btw niet mogelijk, kijkend naar het ontwerp, en naar de gegevens die je wilt opvragen, om de queries opnieuw te maken ZONDER hulp van ACCESS?? Op deze manier kan je zeer waarschijnlijk het 1 en ander aan de queries optimaliseren.

[whoami]

Ik heb geen zin gehad om die query van dichterbij te bekijken, maar gebruik je wel indexen in uw databank?

Op vrijdag 22 februari 2002 17:03 schreef hezik het volgende:

Overigens: MS Access? Moet dat ook de database worden? Doe dat jezelf alsjeblieft niet aan. Wil je het perse wel zo doen, vermijdt dan iig. autoinc velden. Gebruik je die wel dan is binnen een maand de integriteit van je database naar de kloten (sorry dat ik het zeg, maar het is wel zo )

Waarom? Wat zijn uw ervaringen ermee? Ik gebruik meestal als PK een Long Integer veld die ik zelf iedere keer ga gaan ophogen. Voor sommige tables gebruik ik echter wel een AutoInc maar ik heb er nog geen problemen mee gehad.