Zoekquery in phpmaker

[Wooldoor]

Mischien zijn er hier mensen die met het programma phpmaker 5.0 hebben gewerkt, zo niet mischien weten jullie het dan alsnog

Ik een grid gegenereerd met een aantal zoekvelden en een zoekveld daarvoor heet subsidie.
Nu heb ik in mijn database de velden subsidie1, subsidie2 ,subsidie3 ,subsidie4 ,subsidie5.

Als ik ga zoeken met phpmaker 5 naar subsidie zoekt hij automatisch alleen in subsidie1. In het programma zelf is het naar mijn weten niet mogelijk om te zoeken naar de andere subsidie velden.
Dit terwijl het eigenlijk een simpele query is in de vorm van:

SELECT .......
WHERE velda like '%bad%'
OR veldb like '%bad%'
OR veldc like '%bad%'

Alleen nu is de code dusdanig opgebouwd dat ik het niet meer kan lezen.
Het gaat waarschijnlijk om het volgende stuk:

// Return Advanced Search Where based on QueryString parameters

// Field subsidie1
BuildSearchSql($sWhere, $klanten->subsidie1, @$_GET["x_subsidie1"], @$_GET["z_subsidie1"], @$_GET["v_subsidie1"], @$_GET["y_subsidie1"], @$_GET["w_subsidie1"]);

[Janoz]

Nummering in de kolommen betekend een brak database design. Daar is waar je probleem zit dus probeer het daar ook op te lossen.

[Wooldoor]

Ok laten we zeggen ik maar van subsidie 1t/m 5 subside A t/mE dan blijft de vraag nog hetzelfde

[Creepy]

En blijft de opmerking van Janoz ook hetzelfde
Je wilt in dit geval geen herhalende velden in je database hebben, dat is het eerste wat je aanpast zodra je je zaken gaat normaliseren. Als je dat hebt gedaan dan zijn in dit geval je queries ook ineens een stuk makkelijker en leesbaarder en kan je ook makkelijk zoeken met phpmaker.

[Dennahz]

Je kan je inderdaad beter verdiepen in een goed database design. Dit is echt geen werken zo... stel dat er nog meer subsidies bijkomen ga je dan telkens nieuwe tabellen maken? Dat is ook niet te onderhouden op die manier... nu is het 'makkelijk' maar later zit je op elke pagina query's aan te passen etc.

[Wooldoor]

ok mischien is het zo duidelijker

Dit is mijn tabel:

Klant
------------------
Subsidie1 varchar(50)
Subsidie2 varchar(50)
Subsidie3 varchar(50)
Subsidie4 varchar(50)
Subsidie5 varchar(50)


Dit is de index.php met het enige zoekveld:

Subsidie = <dropdownlistbox>

Nieuwe situatie:

Ik wil zoeken met het enige subsidie zoekveld naar alle 5 subsidie velden.
Dus als de inhoud van subsidie1 blaat is en die van subsidie2 is ook blaat en die van 3,4,5 zijn top
dan wil ik als ik zoek op blaat 2 resultaten krijgen.

Nu krijg ik maar 1 resultaat en dat is die van subsidie1

[SchizoDuckie]

En nu verwacht je dus van ons dat wij weten wat voor SQL die vage BuildSearchSql($veelteveelparameters) produceert en hoe je daar ietsin kan hacken?

Zou je niet beter gewoon zelf een goeie searchquery schrijven? zo moeilijk is dat niet namelijk

[Sh4wn]

Uberhaupt gebruik maken van Code Generation progjes is ronduit bagger

Het werkt in alle gevallen beter als je het gewoon zelf doet.

[Creepy]

Het is al duidelijk wat je wilt hoor

Maaruh, pas de index.php aan zodat ie een query genereert zoals jij hem wilt hebben? Lijkt me een kleine moeite. (maar nog steeds heb je een bagger datamodel waardoor je zo'n suffe query moet fixen, ik hoop dat je je dat wel beseft)

[ Voor 7% gewijzigd door Creepy op 14-01-2008 15:56 ]

[Wooldoor]

Ik weet dat jullie een code generator crap vinden maar het werkt prima voor wat ik ermee doe en waar het voor moet dienen. Beter dan ik zelf had kunnen kloppen (nu is dat ook bar weinig )

Maar in ieder geval bedankt.

[Janoz]

We hebben hier helemaal niks tegen codegeneratoren. Deze worden heel veel gebruikt. Je probleem hier heeft ook helemaal niks met de code generator te maken. Wat iedereen je hier probeert uit te leggen is dat je probleem ligt in je database model. Wat je hier omschrijft is een typische 1 op N relatie. Dit sla je op in twee verschillende tabellen waarbij je in de subsidie tabel een referentie naar de klant tabel opneemt. Doe je dit dan kan er keurige en goede code gegenereerd worden.

Leuk leesvoer : http://en.wikipedia.org/wiki/Database_normalization

[Voutloos]

Janoz schreef op maandag 14 januari 2008 @ 21:45:
We hebben hier helemaal niks tegen codegeneratoren. Deze worden heel veel gebruikt.

offtopic:
Het gebruik van de shut-up operator (@) is vaak niet echt mooi, want meestal kan je eerst elegantere checks uitvoeren. Deze code generator zet 5 shut-ups in 1 statement en dat heeft een mens nog nooit gepresteerd. Je eigen debug mogelijkheden om zeep helpen of fouten onderdrukken is toch wel iets waar je later heel erg van kan gaan balen. Maar goed, zolang je deze tool vertrouwt (kan vertrouwen), is het datamodel het grootste probleem.

[Verwijderd]

Ik ben niet echt goed in maar wat ik met database design heb geleerd is volgende. Met de code wat jij hebt ingevoerd kan je alleen in je database het woord die voorkomt vinden '%Bad%'

Dat is wat ik van weet

[Voutloos]

Wat LIKE doet is het probleem van de TS niet, en je legt het bovendien verkeerd uit.
'%' is een wildcard character voor 0 of meerdere willekeurige tekens.