Om lokala SQL-databaser

Med funktionen för lokala SQL-databaser i AIR kan du lagra programdata på en användares lokala dator i flera olika syften. I Adobe AIR finns flera mekanismer för att lagra data lokalt. Varje mekanism har sina specifika fördelar. Nedan följer några exempel på hur du kan använda en lokal SQL-databas i ett AIR-program:

• När det gäller dataorienterade program (till exempel en adressbok) kan du använda en databas för att lagra data för huvudprogrammet.

• När det gäller dokumentorienterade program (i vilka användarna skapar dokument som de vill spara och eventuellt dela med andra) kan varje dokument sparas som en databasfil på valfri plats. (Observera dock att om databasen inte är krypterad kan databasfilen öppnas av ett AIR-program. Kryptering rekommenderas för dokument som innehåller potentiellt känslig information.)

• För nätverksmedvetna program kan du använda en databas för att lagra en lokal cache för programdata eller lagra data temporärt när en nätverksanslutning inte är tillgänglig. Du kan skapa en mekanism för att synkronisera den lokala databasen med ett datalager i nätverket.

• Oavsett vilken typ av program du har kan du använda en databas för att lagra enskilda användares programinställningar, såsom användaralternativ eller programinformation, till exempel fönsters storlek och placering.

En lokal SQL-databas i Adobe AIR lagras som en enskild fil i datorns filsystem. Med SQL-databasmotorn som ingår i körningen kan du skapa och strukturera databasfiler samt ändra och hämta data från en databasfil. Körningen specificerar inte hur eller var databasdata lagras i filsystemet. Varje databas lagras i en enda fil. Du kan ange var databasfilen ska lagras i filsystemet. Du kan få åtkomst till en eller flera separata databaser (det vill säga separata databasfiler) från ett enskilt AIR-program. Eftersom varje databas lagras som en enskild fil i filsystemet kan du leta reda på din databas i enlighet med programmets utformning och operativsystemets begränsningar för filåtkomst. Varje användare kan ha en separat databasfil för sina specifika data, eller så kan en databasfil delas av alla programanvändare på en och samma dator. Eftersom data sparas lokalt på en enskild dator kan de inte delas automatiskt med användare på andra datorer. Motorn för den lokala SQL-databasen kan inte köra SQL-satser mot en fjärrdatabas eller serverbaserad databas.

En relationsdatabas är en mekanism för lagring (och hämtning) av data på en dator. Data är ordnade i tabeller: rader representerar poster eller objekt, och kolumner (kallas ibland ”fält”) delar in varje post i enskilda värden. Ett adressboksprogram skulle till exempel kunna innehålla tabellen ”vänner”. Varje rad i tabellen skulle i så fall representera en enskild vän som lagras i databasen. Tabellens kolumner skulle representera data, till exempel förnamn, efternamn och födelsedatum. För varje vän-rad i tabellen lagras ett separat värde för varje kolumn.

Relationsdatabaser är utformade för att lagra komplexa data, där ett objekt är associerat med eller relaterat till objekt av en annan typ. I en relationsdatabas bör alla data som har en en-till-många-relation (där en enskild post kan vara relaterad till flera poster av en annan typ) delas upp i olika tabeller. Anta att du till exempel vill att ditt adressboksprogram ska lagra flera telefonnummer för varje vän. I så fall är detta en en-till-många-relation. Tabellen ”vänner” skulle innehålla all personlig information för varje vän. Den separata tabellen ”telefonnummer” skulle innehålla alla telefonnummer för alla vänner.

Förutom att lagra information om vänner och telefonnummer skulle data som anger relationen mellan de båda tabellerna behöva lagras i varje tabell, så att de enskilda vänposterna kan matchas med motsvarande telefonnummer. Dessa data kallas en primärnyckel, vilket är en unik identifierare som särskiljer varje rad i en tabell från andra rader i den tabellen. Primärnyckeln kan vara en ”naturlig nyckel”, vilket innebär att den är ett av dataobjekten som naturligt särskiljer varje post i tabellen. Om du vet att ingen av dina vänner i tabellen ”vänner” har samma födelsedatum, kan du använda kolumnen Födelsedatum som primärnyckel (en naturlig nyckel) för denna tabell. Om det inte finns någon naturlig nyckel kan du skapa en separat primär nyckel som t. ex. "vän-id" – ett artificiellt värde som programmet använder för att särskilja rader.

Med en primärnyckel kan du skapa relationer mellan flera tabeller. T. ex., om tabellen "vänner" har en kolumn som heter "vän-id" som innehåller ett unikt nummer för varje rad (varje vän). Den relaterade tabellen ”telefonnummer” kan struktureras med två kolumner: en kolumn med vän-id:t för vännen som telefonnumret tillhör och en kolumn med det faktiska telefonnumret. På så sätt kan alla telefonnummer för en enskild vän sparas i tabellen ”telefonnummer” (oavsett hur många telefonnummer vännen har) och länkas till den relaterade vännen med hjälp av primärnyckeln ”vän-id”. När en primärnyckel från en tabell används i en relaterad tabell för att ange kopplingen mellan posterna, kallas värdet i den relaterade tabellen för ”främmande nyckel”. Till skillnad från många databaser kan du inte skapa begränsningar för främmande nycklar i den lokala databasmotorn i AIR (begränsningar som automatiskt kontrollerar att ett infogat eller uppdaterat värde för en främmande nyckel har en motsvarande rad i primärnyckeltabellen). Relationer för främmande nycklar är en viktig del av strukturen för en relationsdatabas, och du använder främmande nycklar när du skapar relationer mellan tabeller i databasen.

SQL (Structured Query Language) används med relationsdatabaser för att ändra och hämta data. SQL är ett beskrivningsspråk snarare än ett procedurspråk. I stället för att ge datorn instruktioner för hur den ska hämta data anger du önskade data med en SQL-sats. Databasmotorn avgör hur dessa data hämtas.

Språket SQL har standardiserats av ANSI (American National Standards Institute). Den lokala SQL-databasen i Adobe AIR stöder huvuddelen av standarden SQL-92.

Mer specifika beskrivningar för SQL-språket i Adobe AIR finns i SQL-stöd i lokala databaser .

När du arbetar med lokala SQL-databaser i ActionScript 3.0 använder du instanser av dessa klasser i paketet flash.data:

Använd följande klasser i paketet flash.data om du vill ha schemainformation som beskriver strukturen för en databas:

I paketet flash.data finns andra klasser som innehåller konstanter som används med klasserna SQLConnection och SQLColumnSchema:

Följande klasser i paketet flash.events representerar händelser (och konstanter som stöds) som du använder:

Följande klasser i paketet flash.errors ger information om fel vid databasåtgärder:

När du skriver kod för en lokal SQL-databas anger du att databasåtgärderna ska köras i antingen asynkront eller synkront körningsläge. I kodexemplen visas hur du utför varje åtgärd i respektive körningsläge, så att du kan använda det exempel som passar bäst för dig.

I asynkront körningsläge ger du körningen en instruktion. Sedan skickar körningen en händelse när din begärda åtgärd har slutförts eller misslyckats. Först anger du att databasmotorn ska utföra en åtgärd. Databasmotorn arbetar i bakgrunden medan programmet fortsätter att köras som vanligt. När åtgärden har slutförts (eller misslyckats) skickar databasmotorn en händelse. Din kod, som utlöses av händelsen, utför efterföljande åtgärder. Den här metoden har en klar fördel: databasåtgärderna utförs i bakgrunden medan huvudprogramkoden fortsätter att köras som vanligt. Programmet fortsätter att köras även om databasåtgärden tar lång tid att utföra. Viktigast av allt är att användaren kan fortsätta att interagera med programmet utan att skärmen fryser. Däremot kan kod för asynkrona åtgärder vara mer komplicerad att skriva än annan kod. Det kan till exempel vara komplicerat att skriva kod när flera beroende åtgärder måste delas upp i olika händelselyssnarmetoder.

Det är enklare att skriva koden för åtgärder som en enstaka stegsekvens (en uppsättning synkrona åtgärder) än en uppsättning åtgärder indelade i flera händelselyssnarmetoder. Med Adobe AIR kan du även köra databasåtgärder synkront. I synkront körningsläge körs åtgärderna inte i bakgrunden. I stället körs de i samma körningssekvens som all annan programkod. Du anger att databasmotorn ska utföra en åtgärd. Sedan pausas koden medan databasmotorn fortfarande utför sitt arbete. När åtgärden har slutförts fortsätter körningen med nästa rad i din kod.

Huruvida åtgärderna ska köras asynkront eller synkront anges på SQLConnection-nivå. Du kan inte köra vissa åtgärder eller satser synkront och andra asynkront med en enda databasanslutning. Du anger om en SQLConnection-instans ska arbeta i synkront eller asynkront körningsläge genom att anropa en SQLConnection-metod som öppnar databasen. Om du anropar SQLConnection.open() arbetar anslutningen i synkront körningsläge, och om du anropar SQLConnection.openAsync() arbetar anslutningen i asynkront körningsläge. När en SQLConnection-instans har anslutits till en databas via open() eller openAsync() är den kopplad till synkront eller asynkront körningsläge, om du inte stänger och sedan öppnar anslutningen till databasen på nytt.

Varje körningsläge har sina fördelar. De två lägena är till största delen lika, men det finns några skillnader som du bör tänka på när du arbetar i respektive läge. Mer information om detta och förslag på hur du kan arbeta i respektive läge finns i Använda synkrona och asynkrona databasåtgärder .