FileMaker 9.0 - Koppla ihop webshop (MySQL) med FileMaker i praktiken

Skrivet av Ola Andersson
Nyhet: FileMaker 9.0 lanserat idag

Koppla ihop webshop (MySQL) med FileMaker i praktiken
Hur svårt är det då att koppla samman tex en väldans enkel varukorg i MySQL som finns inuti en Joomla-site som heter Simple Caddy med FileMaker Pro, så att jag inifrån FileMaker kan skriva ut ordrar som kommit in i shoppen? Låt oss ta reda på det!

Processen består av fem steg:

1. Köp, ladda hem och installera Actual Technologies drivrutiner för MySQL, de kostar ca $29:95 (endast 207 SEK) per dator.

Version 2.7b av Actual Technoligies Open Source Database drivrutiner släpptes igår (2007-07-10) och fungerar alldeles utmärkt. Open Source Databases paketet version 2.7b består av drivrutiner för MySQL , PostgreSQL och SQLite .

De har även drivrutiner för SQL Server, Sybase, Oracle och Microsoft Access.

(Jag har även testat med MySQL ODBC Connector som sägs skall fungera som leveras gratis av MySQL AB, men jag fick inte den att fungera).

Så här ser disk image ut:

2. Starta Program > Verktyg > ODBC-Administratör och lägg upp en ny System-DSN, ange alla uppgifter för din MySQL-databas som dess adress, username, password mm.

3. Starta FileMaker 9, öppna din databas och under File > Manage > External Data Sources, lägger du till den System-DSN du nyss skapade i steg 2.

4. Gå in på samma ställe File > Manage > Database och gå till relationsdiagrammet. Klicka på knappen för att lägga till en tabellförekomst, välj den data källa du nyss skapde och vips har du tillgång till alla tabeller i den databasen. Välj en.

5. Nu får du automatiskt (som med alla tabeller man skapat inuti FileMaker) en layout för den tabellen och du kan relatera denna tabell till andra FM-tabeller i ditt relationsdiagram och du kan börja fylla i data i FileMaker som direkt synkroniseras med data i MySQL.

MySQL-tabellen är i FileMakers ögon som nästan vilken tabell som helst
Jobbar du i bearbetaläge i en layout som visar poster från en MySQL-tabell och "lämnar posten", så skjuts informationen du just ändrade automatiskt över till MySQL-tabellen. Du kan bläddra, söka, köra manus som ändrar i fälten precis som med andra tabeller.

Det finns ett par undantag från regeln att denna tabell är likadan som andra tabeller, men jag tänkte inte ta upp dessa här om ingen frågar.

Använd tabellen för att göra layout (som vanligt alltså)
Nu kan jag skapa en layout från vilken jag kan skriva ut orderbekräftelser, fakturor mm.

Hur otroligt användbart detta än är så är inte det den enda nyheten i nya FileMaker 9.

Okelidokeli...

* En skillnad, du kan i andra tabeller skapade i Filemaker (aka lokala) skapa fält av alla typer, i en SQL-tabell som används i FileMaker, så kan du bara skapa två typer av fält - beräkningsfält och statistikfält. (Se bild).

* Jag visste sedan tidigare att när man gör sökningar i FileMaker så är default att man söker på ord som börjar med något, dvs Begins With. I andra databaser (tex MySQL) så är det inte så, sökningar är lite petigare där, söker jag tex på Anders i ett fält det står Ola Andersson i så får jag inga träffar. Vid det snabba test jag just gjorde så verkar det dock inte vara så, sökning på Ola, Anders och Ola And ger alla de träffar det skall ge.

* En tredje skillnad - FileMaker tillämpar postlåsning, dvs om en person i en delad databas går in i ett fält i en post, så är den posten låst till den personen, andra kan inte ändra i den samtidigt förräns den personen lämnat fältet och posten. (När de försöker får de ett meddelande om detta). En post från en SQL-databas har ingen postlåsning, flera personer kan alltså gå in och ändra i samma post samtidigt. Istället jämförs posten i det ögonblick man lämnar den med hur den ser ut i SQL-databasen nu. Finns det skillander så får användren en fråga - vill du skriva över?

Det är vad jag kommer på just nu.

Bilden försvann, provar igen:

Notera den lilla knappen "Sync" längst upp i bilden, den kollar och korrigerar, så att de "skugg"-fält som finns i FileMaker är exakt lika som de som finn i källan, dvs tabellen borta i SQL-databasen. Så ändrar man där borta, lägger till och tar bort fält tex, så behöver man bara efteråt trycka på Sync, så blir det lika igen.

Richard, det är på pricken vad jag tror. FileMaker har så många styrkor i sig, så att positionera sig på marknaden som ett front-end mot SQL-databaser är inte en position de eftersträvar. När det gäller prestanda och kapacitet för det stora antalet med applikationer så ligger faktiskt inte FileMaker så väldans långt efter databaser som har gjort sig av med GUI till förmån för prestanda så att "reducera sig" till "front-end" gentemot dessa är inte i deras strategi.

Nu när jag har haft några dagar att fundera så hittar jag fler och fler roliga projekt man kan bygga med denna funktion.

För att kunna importera så måste både Filemaker och Access vara igång, är de det? Det låter på dig lite som om du jobbar med filer på något sätt.

Du måste ha rätt Actual Technologies drivrutiner, de för just access, inte de som är för Open Source.

Det andra är att du måste sätta upp en ODBC-datakälla i in datorn för Access med drivrutinerna för Actual Technologies (inte i Access-datorn, i din dator).

Det tredje är att du måste ha User/Pass i Access som kan ansluta utifrån.

Det fjärde är sedan att göra Arkiv > Importera i FileMaker, välja ODBC-import, välja datakällan som är för Access, logga in och sedan para ihop fälten och trycka på "Kör" (eller Ok).

Jo, du får nog beskriva när, vad och hur det inte fungerar för att kunna få mer specifik hjälp, men börja med listan ovan och säg vilka steg du har gjort/inte gjort och var det går it pipsvängen.

Saker som kan ställa till det - brandväggar, TCP/IP-inställningar. Brandväggen i din dator, din router, Accessdatorns router och Access-datorns brandvägg måste alla släppa igenom trafik på porten för detta. Vet tyvärr inte vilken det är.

Jepp, du blandar ihop äpplen och päron. Men oroa dig inte, det är ganska så lätt när man förstått hur saker och ting hänger samman och du är inte den första som trott att FileMaker kan läsa Access-databasfiler.

Om du tänker dig att FileMaker är en telefon i en lägenhet i ett hus och Access är en telefon i en lägenhet i ett annat hus till att börja med, så är ODBC helt enkelt sladdar och telefonväxlar som gör det möjligt för FileMaker att "ringa" Access och be om information. Men denna metafor haltar lite i de kommande punkterna.

För det första så måste alltså både FileMaker och Access vara igång och båda måste ha varsitt dokument öppet.

På FileMaker-sidan så måste man skapa en datakälla med ODBC-administratör, det är då man väljer den drivrutin från Actual Technologies som är för Access. När man har lagt upp en datakälla motsvarar det att ha talat om för telefonen att det finns ett nummer den kan ringa som är till Access. När du skapar en datakälla anger du domännamn/IP-nummer, användarnamn och lösenord och en viss databas och ibland en viss tabell också. Allt detta kan man likna vid ett telefonnummer till Access.

På Accessidan måste du alltså inte förbereda så mycket, tex behöver du inte där skapa en ODBC-datakälla, det är ju Access som blir "uppringd", men du måste ha ordnat ett par saker:

1. Att Access är "nåbar" utifrån genom alla brandväggar på vägen (dator, leverantören). Det portnummer det gäller (det får du googla fram själv) få ralltså inte vara spärrat på hela vägen mellan din dator, brandvägg fram till din leverantörs brandvägg/dator.

2. Att det finns ett rätt stavat användarnamn och lösenord för databasen som kan ansluta från en annan dator (i MySQL tex så har varje användarnamn en parameter som talar om huruvida detta användarnamn är välkommet att ansluta från localhost eller om det är välkommet att anslut utifrån datorn). Jag nämner detta för jag vet inte hur det är i Access med användarnamn och lösenord. Med tanke på hur det är i SQL Server som också är från Microsoft i vilken det är rena djungeln med säkerhetsparametrar, så bör du alltså kolla detta.

3. Att Access är igång med databasen öppen.

Sedan är det bara att importera
När du sedan i FileMaker väljar Arkiv > Importera > ODBC-datakälla så skall din datakälla (dvs Access) finnas där.

FileMaker "ringer upp" och börjar med att be om lite information, som tex vilka tabeller som finns i Access. Du väljer en tabell (i samband med detta anger du eventuellt användarnamn/lösenord, om du inte valde att lagra dessa i datakällan) och följer stegen vidare att para ihop fält mellan datakällan (dvs Access) och fälten i din FileMaker-tabell. Det finns ett alternativ att para ihop baserat på namn, välj det.

Nu snackar alltså programmet FileMaker med programmet Access och de använder sig av språket SQL. FIleMaker ber Access om data ur "dokumentet" dvs databasen som Access har öppet och FileMaker lägger in det i dokumentet, dvs databasen som FileMaker har öppet.

Skillnaden mellan hur du föreställer dig att det fungerar och hur det verkligen fungerar är att FileMaker inte läser Access databasfil direkt från disken, det är det Access som gör. FileMaker skickar SQL-kommandon som tex "SELECT * FROM TABLE Websvar" till Access i en annan dator och Access läser filen från disken, söker fram poster och levererar dem till FileMaker.

Du skall alltså inte ladda hem filen först och ja, det måste finnas en Access igång någonstans.

Förstår du hur det fungerar nu?

Jag tror jag har förklarat så mycket jag kan förklara? Alla steg du behöver göra står beskrivna ovan och hur allt fungerar också. Du måste följa stegen och berätta hur i vilket steg det inte fungerar.

Jo, en gång till. FileMaker läser inte filen, Access läser filen. FIleMaker frågar Access: -"Du har du några poster åt mig?" Access svarar - "Det skall väl du skita i!?".

(Steget efter din bild ovan är att para ihop fält i FileMaker.)

Du beskriver förresten inte tillräckligt tydligt vad du gör för att jag skall kunna hjälpa dig mera.

Hör gärna av dig oavsett hur det går, forumet är inte bara till för att få svar på sin egen fråga, det är meningen att man skall dela med sig efteråt vad som funkade och inte.

Jo, det verkar fortfarande som om en viss grundläggande grej inte har gått fram, jag tolkar första meningen ovan som att du fortfarande tänker att FileMaker skall läsa FILEN som utgör Accessdatabasen då du skriver .mdb->.fp7. Så är det alltså inte.

Tänk dig att Access är en person som håller en ordbok i näven och att FileMaker är också en person som lyfter luren och ringer till Access. Ordboken i denna metafor är alltså mdb-filen. FileMaker frågar Access i detta telefonsamtal hur man stavar till tex Aardvark och FileMaker hör svaret och skriver det på en lapp, dvs in i sin .fp7-fil.

I alla inlägg du skrivit hitills verkar det som om det är just det här som du inte greppar och jag är rädd att alla dina försök att lösa detta problem kommer att misslyckas för att du försöker få FM att läsa ordboken själv som Access håller i. Är du med?

Hur gick det med detta? En solklar anledning till att det inte kanske fungerar (som jag nämnde ovan måste kollas) är att om du sitter hemma med FileMaker i din dator och Access är igång på webbhotellet i den datorn så har ni sammanlagt fyra brandväggar er emellan som alla måste släppa igenom trafik på de portnummer det gäller. Din dators brandvägg - din router - webbhotellets router/brandvägg - webbhotellets dators brandvägg.

En annan sak som kan vara felet nu när jag funderat lite är att Access faktiskt inte är igång därborta. Varje gång det kommer in en anmälan så öppnas en fil (Acess-databasen), den nya registeringen skrivs in i filen och sedan sparas filen igen. Programmet Access är alltså inte igång på servern. Man skall i det fallet få det bytt på webbhotellet till ett annat filformat på filen som registeringarna sparas i, tex Excel, Text, CSV osv, alla är format som FileMaker och massor med andra databasprogram kan läsa. (Den som valt Access borde ha en hatt gjord av aluminiumfolie så man vet vilka de är de där).

Den hanterar visst åäö.

Prova denna inställning istället:

Kan också rapportera att jag har efter kontakt med Actual Technologies mycket trevliga och kompetenta support fått lära mig hur man gör för att skicka SQL-kommandon som innehåller åäö till MySQL från FileMaker med denna drivrutin.

Notera att detta är lite överkurs från diskussionen i denna tråd som bygger på inbyggda funktioner i FileMaker som alltså inte kräver att man skriver en massa SQL-kommandon.

Säg tex att du vill göra en update av en post och du vill skicka över ett fält som innehåller texten "Överjordiskt vacker och frustrerande förtjusande" och det fältet heter i MySQL tabellen "BokenOmOla" "KapitelTitel" och det finns ett ID-fält också.

Normalt skriver man så här (egentligen gör man detta som ett beräkningsfält i FileMaker, men jag vill inte krångla till denna beskrivning alltför mycket just nu så det kommer lite längre ner) :

UPDATE BokenOmOla
SET KapitelTitel = 'Överjordiskt vacker och frustrerande förtjusande' WHERE ID=7;

Eftersom varje åäö "käkar upp" (varför den gör det är tydligen pga omständigheter utanför Actual Technologies kontroll) ett tecken i SQL-kommandot bakifrån så är vad som skickas istället detta:

UPDATE BokenOmOla
SET KapitelTitel = 'Överjordiskt vacker och frustrerande förtjusande' WHERE ID=

och man får ett syntax error. (Två ö tar bort ; och 7)

Alltså får man istället slänga dit en massa semikolon att "ta av" som då blir tex:

UPDATE BokenOmOla
SET KapitelTitel = 'Överjordiskt vacker och frustrerande förtjusande' WHERE ID=7;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

I ett beräkningsfält inuti FileMaker för ett UPDATE-kommando kan det se ut så här:

"UPDATE BokenOmOla
SET KapitelTitel = "'" & KapitelTitel & "' WHERE ID=" & ID_MySQL & ";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;"

...om det nu finns fält i FileMaker som heter KapitelTitel och ID_MySQL.