ExecuteSQL, alleen vraagteken terug

[dudematters]

Ik heb een werkende ODBC koppeling met een MySQL database gemaakt. In Filemaker Pro Advanced 13 heb ik een calculatie gemaakt ;

 

ExecuteSQL ( "SELECT DISTINCT kp_postmeta.meta_value FROM kp_postmeta WHERE kp_postmeta.post_id = " & ID & " AND kp_postmeta.meta_key = '_from_email'" ; "" ; "" )

 

Maar deze geeft alleen een ? terug, ik begrijp niet waarom. Als ik deze SELECT op mijn database uitvoer krijg ik keurig netjes mijn waarde terug, 1 stuks (wat ik ook wil). Het veld ID geef ik mee uit mijn tabel...

[menno]

is

post_id 

in de MySQL-tabel een nummer? Je kan

kp_postmeta.

uit je query weglaten want je hebt geen alias gedeclareerd

je kan de query ook nog een beetje herschrijven:

ExecuteSQL ( "SELECT DISTINCT meta_value FROM kp_postmeta WHERE post_id = ? AND meta_key = ?" ; "" ; "" ; ID ; "_from_email" )

[dudematters]

Het zijn twee tabellen,

 

1. kp_posts

2. kp_postmeta

 

Ik benader de kp_postmeta vanuit een FM layout met als base ' kp_posts' (waarvan ik de ID nodig heb). In kp_posts staan alle unieke ID's, in kp_postmeta kan deze id vaker voorkomen, maar in combinatie met de "_from_email" komt deze maar 1x voor. De distict is eigenlijk alleen maar een test om te kijken of dat uitmaakte. De query hoef ik alleen op kp_postmeta los te laten want daar staat de data die ik terug wil hebben. Omdat ik deze vanuit kp_posts ophaal leek het mij logisch dat ik de kp_postmeta. mee gaf... ?

[dudematters]

Dag Menno,

 

Dank voor je reactie. Ik neem aan dat ik in jou voorbeeld de ? moet vervangen door de velden ID en tekst '_from_email' ?

En als laatste twee parameters geef je ID en "_from_email" mee, dat is wat ik terug krijg?

 

Ik heb in de tabel kp_postmeta een veld staan: meta_value en die inhoud wil ik terug krijgen, alleen die, geen id (die weet ik al).

[Peter Wagemans]

Ik denk aan 3 dingen die je eens zou kunnen proberen:

Zet Evaluationerror rond je je query, en je zal te weten komen wat het vraagteken betekent, je krijgt dan een filemaker error code terug die je een hint geeft van het probleem.

Het zou kunnen dat er door de ess koppeling bepaalde queries niet kunnen. Kopieer de ess tabel lokaal en probeer de query opnieuw, heb je geen error dan is dat redelijk conclusief.

Of je download een demo versie van de dosql plug-in, die zal je een meer informatie fout dialoog geven.

[menno]

Ik neem aan dat ik in jou voorbeeld de ? moet vervangen door de velden ID en tekst '_from_email'

Nee je hoeft niets in die query te vervangen. De vraagtekens in de query zijn placeholders voor de parameters die verderop in de formule staan:

 

ExecuteSQL ( "SELECT DISTINCT meta_value FROM kp_postmeta WHERE post_id = ? AND meta_key = ? " ; "" ; "" ; ID ; "_from_email" )

 

Ieder opvolgend vraagteken hoort in dezelfde volgorde bij de parameter op dezelfde positie in de parameterlijst. De eerste 2 parameters zijn respectievelijk de kolomscheiding en de recordscheiding. Als je niets opgeeft wordt door filemaker standaard de komma ( , ) en de wagenterugloop ( ¶ ), daarna volgen de parameters die Filemaker zelf in de query op de plek van de vraagtekens invult. Filemaker zoekt min of meer zelf uit wat het juiste formaat is.

 

Filemaker raadt, meen ik, eigenlijk af om ExecuteSQL() op ESS-tabellen te gebruiken, ik weet het niet helemaal zeker, maar ik dacht dat Jon Tatcher op de afgelopen summit daar iets over heeft gezegd.

 

Verder zijn de tips van Peter ook erg waardevol om uit te vinden wat er precies verkeerd in je query is.

[dudematters]

Dank Peter en Menno, ik heb het werkend nu en begrijp het beter.

 

Wat me nu opvalt is dat het heel erg traag is. Ik zoek vanuit een lokale Filemaker gegevens op uit een webserver (die op het internet draait). Het zijn niet extreem veel gegevens maar een overzicht van alle kp_posts en de daarbij opgezochte gegevens in kp_postsmeta doet over 3000 records echt een paar minuten. Dat is bijna niet bruikbaar. De queries zijn zoals je ziet niet zwaar, mysql geeft ze direct terug omdat ze zo specifiek zijn. Maar in een overzicht waarbij alle sub-tabel gegevens moeten worden opgehaald is het niet te doen.

[menno]

Wat me nu opvalt is dat het heel erg traag is.

Dat is ook de reden dan FMI het gebruik van de functie ExecuteSQL op ESS-tabellen afraadt.

 

Er wordt via ODBC met SQL een tabel opgevraagd in fragmenten van een x aantal records en dat wordt getoond en een FM-zoek wordt in de achtergrond omgezet in een SQL-statement en afhankelijk van het resultaat wordt dan alles getoond of in fragmenten. Ga je nu ExecuteSQL op dit resultaat loslaten, dan kan je mazzel hebben en dan gaat het snel, maar meestal zal je last hebben van de fragmentatie en moet een SQL-statement meerdere keren in delen worden "vertaald" en dan wordt het heel traag zoals jij nu ervaart. Je kan dus beter gaan kijken of je niet gewoon zoekopdrachten kunt doen

[dudematters]

Dank je wel Menno voor je toelichting. Ik was al bezig anders te denken in oplossingen. Het komt mij steeds vaker voor dat FM wel nieuwe functies inbouwt maar deze vaak niet erg breed toepasbaar zijn, het lijkt er op dat ze nog niet af zijn soms... Ik bedoel, in deze tijd communiceren met een MySQL tabel, hoe moeilijk kan dat zijn.... als je dan toch al functies aan het maken bent zoals ExecuteSQL....

[menno]

ExecuteSQL is vooral bedoeld om buiten de binnen FM zo belangrijke context gegevens uit FM-tabellen te kunnen halen. ESS is bedoeld om data uit andere tabellen dan FM-tabellen te kunnen halen mbv ODBC. Deze twee functies "over elkaar heen leggen" gaat gewoon niet werken omdat ze niet met die focus zijn gebouwd (en andere functies zijn daarvoor beschikbaar), het zou mi toch zoiets zijn als met een ferrari scuderia te proberen terrein te rijden.

[dudematters]

In mijn, wellicht simpele benadering, dacht ik dat als je een ESS (ODBC) verbinding heb (die heb ik) de ExecuteSQL een functie was om SQL opdrachten via deze ODBC connectie uit te voeren. Aan de hand van jou opmerking begrijp ik dat ik dit niet helemaal goed interpreteer.

[hans erik]

Dat klopt, het is zoals Menno zegt: de executeSQL() functie is voor gebruik binnen FMP. En voor het maken van grotere selecties is een nadeel dat het resultaat altijd terugkomt in de vorm van een tekstvarariabele, niet als 'tabel' zoals bij SQL databases het geval is. Wil je het resultaat in een tabel zetten dan zul je rijen en kolommen moeten parsen en FMP records aanmaken, in een loop.

 

Maar dat gezegd hebbende: je hebt toch een werkende ESS / ODBC koppeling. Dus OF je kunt met een FileMaker 'Go to Releated Record' of zoekopdracht je records eruit hengelen. Of je gebruikt de ExecuteSQL SCRIPTSTAP om een complexe SQL direct op MySQL uit te voeren en je importeert het resultaat in FileMaker.

 

Ik denk dat de eerste optie in jouw geval de beste is.