[SQL] Vreemde resultaten van ASP naar PHP

[LiquidSmoke]

Ik ben bezig om een ASP pagina naar PHP te vertalen;

Het gaat om een selectie uit een access database.

De database heeft 2 tabellen; persoon en vestigingen
en de relatie tussen de 2 is persoon.vestigingid en persoon.unid.

Ik selecteer een hoop velden en zoek deze als volgt in asp:

code:

FROM persoon, vestiging WHERE 
vestiging.unid = persoon.vestigingid AND ((persoon.archiefredenid Is Null) AND 
(persoon.achternaam Like '%::Achternaam::%')

en in php doe ik nu dit

code:

FROM persoon, vestiging WHERE 
vestiging.unid = persoon.vestigingid AND ((persoon.archiefredenid Is Null)  AND 
(persoon.achternaam Like '%$zoek_naam%')

Op de een of andere manier krijg ik alle velden uit persoon goed geretourneerd (naam telefoonnummer etc), maar 2x
uit de tabel vestiging (plaas, locatie etc).

code:

Naam:   Pietje
Email:  [e-mail]
Afdeling    afdeling
Functie:    functie
Telefoon: telefoon  
Mobiel: mobiel
Bezoek adres:   Teststraat1, 0000XX, Amsterdam

Naam:   Pietje
Email:  [e-mail]
Afdeling    afdeling
Functie:    functie
Telefoon:   telefoon
Mobiel: mobiel
Bezoek adres:   Teststraat2, 1234AA, Rotterdam

M.a.w alles uit de tabel persoon is goed opgehaald en gefilterd, maar voor vestiging krijg ik meerdere resultaten, waar dan dezelfde naam bij gegooid wordt.

Ik krijg er inmiddels geen touw meer aan vast geknoopt...

[Verwijderd]

dit is toch een SQL/MySQL probleem? en geen ASP/PHP probleem?

Ik zou eens kijken voor de JOIN functie van sql/mysql, dat dient volgens mij om 2 tabellen te selecteren en aan elkaar te hangen.

Edit: ah, een acces database, never mind. Maar toch eens kijken om te werken met een Join. In Acces zelf kan je trouwens je Queries grafisch opstellen en uitproberen.

[ Voor 30% gewijzigd door Verwijderd op 30-01-2008 22:54 ]

[LiquidSmoke]

idd een SQL probleem ja...

Inner Joins (relaties gelegd via access) heb ik geprobeerd en ik kom op exact hetzelfde resultaat uit...

Access... i know maar het is iets wat tijdelijk offsite moet draaien en er is geen MySQL beschikbaar

[Wolfboy]

Is vestiging.unid wel uniek?
Het klinkt mij namelijk gewoon als een standaard join waarbij vestiging.unid niet uniek is en dus 2 rijen geeft.

[Dido]

Van wat ik begrijp heb je dus Pietje in vestiging 1 en Pietje in vestiging 2. Wat is je probleem nu?

[LiquidSmoke]

Pietje hoort maar in 1 vestiging thuis; en ja, vestiging.unid is uniek (primary key zelfs).

Ik heb het nu met een left join geprobeerd, maar dan krijg ik sowieso dubbele results...

In PHP kan ik het er makkelijk uitfilteren natuuurlijk, maar het lijkt me ook te moeten kunnen vanuit de query

[Verwijderd]

distinct

[LiquidSmoke]

Ik kom er net wel achter dat het verschil in hoofdletter gebruik zit;

vestiging.unid=2B005u (Vestiging1)
vestiging.unid=2B005U (Vestiging2)

Select distinct maakt hier niet uit...

Ik test het nu ff vanuit Access, in PHP maak ik gebruik van de ODBC connector voor Ms Access

/edit:

Hm, wanneer ik alleen records retourneer zonder een WHERE clause gaat het goed, maar met WHERE dan wordt er niet meer gekeken naar hoofdletters en de id-velden.

Is dit normaal of zit ik nu iets geks te doen?

[ Voor 32% gewijzigd door LiquidSmoke op 31-01-2008 08:24 ]

[moozzuzz]

ODBC voorziet wellicht in tolower() of toupper() - achtige constructies: LCase() of UCase() vertelt de doc me.

[NMe]

Waar hoort mijn topic?

WEB>>PRG

[LiquidSmoke]

Idd...

Helaas kan ik dit niet gebruiken, omdat de vestiging met hoofdletter of kleine letter zou kunnen zijn...

Ik probeer nu in access het tabelontwerp te wijzigen zodat het vestiging.unid Geindexeerd zonder duplicaten zou zijn krijg ik een fout omdat er velden niet uniek zouden zijn.

Ik heb wel e.a. gevonden over collatie, maar volgens mij maalt access daar niet echt om.

hm, ik denk dat een categorie move trouwens wel op zijn plaats is...

[Moraelyn]

id wijzigen of is dat een probleem?

[LiquidSmoke]

Mja het zijn plm 80 locaties, en 1573 personen... en aangezien de odbc driver niet goed omgaat met hoofdletters en kleine letters zal dus bijna alles met de hand moeten.

Ik ben er iig wel uit dat het aan het hoofdlettergebruik ligt. de orginele database draait op MSSQL, die er blijkbaar toch beter mee omgaat...

[TheRookie]

met die UCase & LCase converteer je vziw alles naar Upper resp. Lower case, dan zou het hoofdlettergebruik in de originele velden niet uit mogen maken

[Moraelyn]

TheRookie schreef op donderdag 31 januari 2008 @ 13:20:
met die UCase & LCase converteer je vziw alles naar Upper resp. Lower case, dan zou het hoofdlettergebruik in de originele velden niet uit mogen maken

Dat gaat natuurlijk niet werken. Je weet immers van te voren niet welke vestiging de goede is. Dit kan de vestiging zijn met de kleine letter of de vestiging met de hoofdletter.

[bigbeng]

Gebruik van strings als sleutels is al niet zo handig, maar case-sensitive strings??? Wordt het niet eens tijd om je database ontwerp tegen het licht te houden?

[TheRookie]

Je hebt helemaal gelijk; had de opmerking van de TS anders geïnterpreteerd dan bedoeld.
licht offtopic: ligt het aan mij of is de opbouw van vestiging.unid niet zo heel handig gekozen ?

[LiquidSmoke]

Lol, het ontwerp is niet van mij, maar van een zeer bekend nederlands bedrijf

Ik heb nu het volgende gedaan;

Een testomgeving met SQL Server 2000 SP4 Developer edition, hier de complete database naartoe gepompt (via enterprise manager, dus rechtstreeks).

Alles werkte in 1 keer, hier werkt de case sensitivity dus wel.

Nu draait op de offsite locatie wel een MySQL database, ook hier heb ik alles naartoe gepompt via MSSQL2MYSQL, hier weer hetzelfde probleem.

Het is dus het crappy design wat voor problemen zorgt.

Nah dan maar zorgen dat daar ook Mssql2000 gaat draaien (tis maar tijdelijk).

Tenzij iemand een magische optie heeft om binnen ODBC/MySQL case sensitivity in te schakelen....

[Wolfboy]

Zoals mensen al hebben gezegd, gewoon LCase gebruiken.
SELECT a, b FROM foo, bar WHERE LCase(foo.id) = LCase(bar.foo_id)

[Moraelyn]

Wolfboy schreef op vrijdag 01 februari 2008 @ 04:10:
Zoals mensen al hebben gezegd, gewoon LCase gebruiken.
SELECT a, b FROM foo, bar WHERE LCase(foo.id) = LCase(bar.foo_id)

En dan levert het nog steeds twee records op en dat wil de TS niet. Geen optie dus

vestiging.unid=2B005u (Vestiging1)
vestiging.unid=2B005U (Vestiging2)

[BHR]

Misschien helpt binary comparison (mysql)?
http://dev.mysql.com/doc/refman/5.1/en/cast-functions.html

[ Voor 4% gewijzigd door BHR op 01-02-2008 14:11 ]

[LiquidSmoke]

Tnx voor tip, had er nog niet van gehoord (ben verder niet zo bekend met SQL)...

Inmiddels is er een Mssql 2000 server in de lucht, maar voor later zal ik binary comparison eens proberen...