[MySQL] dubbele LEFT OUTER JOIN = empty set

[Not Pingu]

ik ben bezig met de ontwikkeling van een forum, en naast MS Access en SQL Server ondersteuning wil ik er nu ook MySQL aan toevoegen. hierbij stuit ik echter op wat probleempjes, zoals o.a.:

3 tabellen in pseudo-sql:

TABLE tblCategory:
CatID INTEGER,
CatName VARCHAR(16)

TABLE tblBoard:
BrdID INTEGER,
BrdTitle VARCHAR(16),
BrdCat INTEGER, (komt overeen met een tblCategory.CatID)
BrdRestrict INTEGER (komt overeen met een tblUsergroup.UgrID)

TABLE tblUsergroup:
UgrID INTEGER,
UgrName VARCHAR(16)

Nu heb ik de query:
SELECT CatName, BrdTitle, UgrName
FROM tblCategory LEFT OUTER JOIN (tblBoard LEFT OUTER JOIN tblUsergroup ON tblBoard.BrdRestrict = tblUsergroup.UgrID)
ON tblCategory.CatID = tblBoard.BrdRestrict;

Deze query geeft in Access ook resultaten als er alleen een of meer categorieen zijn, maar geen boards of bijbehorende usergroups.
In MySQL geeft ie alleen resultaten als er een categorie EN een bijbehorend board (of meer) bestaan. Ik wil dat de categorieen ook worden getoond als er geen bijbehorende boards zijn.

Interpreteert MySQL een LEFT OUTER JOIN anders dan Access en SQL Server? hoe kan ik dit oplossen? many thanks.

[ACM]

Probeer het es zonder de nesting?
SELECT CatName, BrdTitle, UgrName
FROM tblCategory LEFT OUTER JOIN tblBoard ON tblCategory.CatID = tblBoard.BrdRestrict
LEFT OUTER JOIN tblUsergroup ON tblBoard.BrdRestrict = tblUsergroup.UgrID

?

[Not Pingu]

lol... ok dat was simpeler dan ik dacht, maar nu geeft deze query weer een error in MS Access

tot nu toe heb ik de minieme verschillen tussen MS Access syntax en SQL Server syntax kunnen afvangen door een paar functies die datetime velden een ' ' danwel een# # eromheen geven e.d., maar om paging zowel in MySQL als in Access en SQL server mogelijk te maken wordt het al wat moeilijker. en dan nog een vervanging zien te vinden voor Dateadd()

iig bedankt

[Not Pingu]

Ik heb nog een vraagje m.b.t. MySQL:

Ik heb een query "SELECT MAX(BrdID) as BrdMax FROM tblBoard"
Deze query wordt gebruikt om bij het aanmaken van een nieuw board het hoogste boardID uit de database op te halen, zodat er een nieuw ID voor het aan te maken board berekend kan worden.

Probleem is er echter op het moment dat er nog geen boards in de database staan. Als ik deze query in de mysql monitor uitvoer, krijg ik terug:

+--------+
| brdmax |
+--------+
| NULL |
+--------+

dit zou erop moeten duiden dat de waarde in BrdMax null is, maar als ik dit in ASP test dmv. If IsNull(Recordset("BrdMax")) Then, geeft ie steevast aan dat de waarde niet null is.

Het casten naar een string of integer levert steevast een 'Execption occured' mededeling op, een Response.Write dus ook. TypeName(Recordset("BrdMax")) levert type 'field' op.

mijn vraag: hoe kan ik testen of het veld BrdMax leeg is?

[marty]

Gunp01nt schreef op 12 June 2003 @ 13:54:mijn vraag: hoe kan ik testen of het veld BrdMax leeg is?

Leeg of NULL?
om te controleren of ie leeg is zou gewoon kunnen kijken of gelijk is aan niets
(in php is dat == ""), zal in asp wel netzoiets zijn

je kunt in mysql trouwens ook controleren of iets NULL is en afhankelijk daarvan een andere waarde teruggeven:

http://www.mysql.com/doc/en/Control_flow_functions.html

Misschien dat je daar nog wat aan heb

[ Voor 28% gewijzigd door marty op 12-06-2003 14:00 ]

[DeverauX]

mijn vraag: hoe kan ik testen of het veld BrdMax leeg is?

Ik heb geen idee hoe MySQL omgaat met NULL in het geval van een agregated function, maar je zou dit in ieder geval gewoon in de applicatie moeten kunnen opvangen, en daar gaat het dan ook fout.
Aangezien de functie IsNULL een booleaanse waarde retourneerd zou je dit in je If-statement moeten meenemen

Zie ook:
IsNull Function

[Not Pingu]

Marty:
thanks, maar dat zou mijn queries weer MySQL specifiek maken, terwijl ik ook compatibiliteit wil houden met Access en SQL Server.

Deveraux:
Ik dacht altijd dat je een boolean waarde in een IF statement niet hoeft te checken (iets 'is' of het 'is niet'), maar dat blijkt hier dus niet op te gaan... thx

overigens loop ik met MySQL tegen zoveel problemen aan dat ik me afvraag of het zin heeft hiermee verder te gaan

[marty]

Gunp01nt schreef op 12 June 2003 @ 15:50:
Marty:
thanks, maar dat zou mijn queries weer MySQL specifiek maken, terwijl ik ook compatibiliteit wil houden met Access en SQL Server.

Volgens mij is je probleem dat als je in ASP zit je het onderscheid niet meer ziet tussen een lege waarde en NULL (de afwezigheid van waarde). Met die functie die ik je net gaf zou je de NULL waarde gewoon als string 'NULL' kunnen retourneren. Je verliest daar niet zoveel mee hoor. Overigens moet je je wel afvragen of het zin heeft hierin onderscheid te maken in asp. Zoals ik al eerder zei, als het niet uit maakt of ie leeg is of NULL, dan kun je gewoon op leeg vergelijken.

overigens loop ik met MySQL tegen zoveel problemen aan dat ik me afvraag of het zin heeft hiermee verder te gaan

Nee Access wordt je vrolijk van

[Not Pingu]

marty schreef op 12 June 2003 @ 16:38:
[...]

Volgens mij is je probleem dat als je in ASP zit je het onderscheid niet meer ziet tussen een lege waarde en NULL (de afwezigheid van waarde). Met die functie die ik je net gaf zou je de NULL waarde gewoon als string 'NULL' kunnen retourneren. Je verliest daar niet zoveel mee hoor. Overigens moet je je wel afvragen of het zin heeft hierin onderscheid te maken in asp. Zoals ik al eerder zei, als het niet uit maakt of ie leeg is of NULL, dan kun je gewoon op leeg vergelijken.

maar bij het casten van de waarde uit de recordset naar een string, geeft ie een Exception occurred-error, zelfde als ik em naar een integer cast.

[...]

Nee Access wordt je vrolijk van

eigenlijk is het niet zozeer dat MySQL slecht is (hoewel het wel frustrerend is dat een aantal dingen heel anders zijn dan bij SQL Server/Access, en dat je geen subqueries kunt gebruiken). misschien dat ik minder problemen had gehad als ik van het begin af aan ook voor MySQL had ontworpen. maar dan nog zijn er queries die ik zonder subquery niet voor elkaar krijg en dus niet in MySQL kunnen.

[Bosmonster]

Waarom zou je proberen voor alle DB's dezelfde queries te gebruiken Tis toch veel makkelijker en efficienter om gewoon per DB een query-set bij te houden oid...

Dat is in ieder geval een stuk gebruikelijker en ook flexibeler in de toekomst (mocht er nog eens een DB bijkomen hoef je niet al je DB's weer te testen omdat je alle queries weer moet nalopen)

[Not Pingu]

daar heb ik ook al over na zitten denken, maar omdat het voor de overstap van Access naar SQL server niet nodig was, heb ik dat niet gedaan.

en om nou alle queries in een array of in aparte variabelen te stoppen lijkt me ook geen goed plan omdat die dan op elke pagina in het geheugen geladen worden. of zou gebruik maken van functies hier helpen?

bijkomend probleem is dan wel weer dat bijv het pagen van een recordset voor MySQL anders moet dan voor MS SQL (MySQL ondersteunt geen bookmarks). god weet waar het dan ophoudt met dingen die je per DBMS specifiek moet ontwerpen wil je op andere DBMS's voorbereid zijn.