Fil- och katalogstruktur per datamapp

Kan någon säga något om vad för filer och mappar per datamapp som behövs för att köra Disgens databas? Tidigare var det en mängd filer med index, flockar och liknande. I och med att det är SQLite som används som databas i Disgen 2016 borde det väl bara vara en fil per datakälla, men eftersom jag inte har nya versionen vet jag inte. Min fundering gäller bl.a. om jag skulle kunna placera databas-filen på en webb-server och läsa den med ex. PHP. Är det något i licensen som hindrar mig från att accessa databasen på detta sätt?

sqlite-filen, alltså data\disgen.db i datamappen, innehåller i princip allt utom inställningar samt vissa delar av kartinformationen. Bilder och länkade dokument ligger som lösa filer.

Det borde gå utmärkt att kopiera runt databasfilen och läsa den med andra program. Dela gärna med dig av koden om du gör något som andra kan ha nytta av eller kan ha som exempel.

Det vi inte lovar är att datamodellen/databasformatet är lika mellan olika versioner av Disgen. Det kan rentav ändra sig vid någon liten uppdatering även om det då knappast blir någon stor ändring. Det finns ett versionsnummer i en av tabellerna som koden kan kontrollera för att se om det är en känd version eller inte.

Tack, ska undersöka detta när jag skaffar nya versionen.

Citat:

---

Ursprungligen postat av DanielBerglund

...läsa den med andra program...

---

Vilken metod för att förhindra samtidig skrivåtkomst kommer att dokumenteras?

Ingen - vem har talat om skrivning?

Kopierar man filen till en helt annan server och läser den där med andra program som man gör själv, får man också göra sin egen låsning om man tycker det behövs.

Ponera två eller flera olika samtidiga Disgenklienter mot en och samma databas? Då lär väl någon låsningsmekanism på någon nivå behövas.

Høres ut som noen ønsker vil medføre behov for en multitier-løsning ?

Kurant å lage i Delphi. Problemet er å bestemme seg for hva slags løsning, minst 3 forskjellige varianter out-of-the-box, men mest populært en REST-løsning for tiden.

Citat:

---

Ursprungligen postat av BrJohan

Ponera två eller flera olika samtidiga Disgenklienter mot en och samma databas? Då lär väl någon låsningsmekanism på någon nivå behövas.

---

Riktigt. Det finns en tabell i databasen där Disgen skriver en installationsunik identifierare. Finns denna i databasen betraktas den som låst av Disgen. När Disgen avslutas tas raden bort och databasen betraktas som olåst. Kraschar Disgen står raden kvar, men vid nästa start kan Disgen se vem som skrev den och då antingen fråga användaren om låset ska brytas eller ta bort låset med automatik.

Som svar: bra! Som semaforprincip: diskutabel - men betydligt bättre än ingen. Vore inte utnyttjande av faciliteterna i WAL (Write Ahead Logging) att föredra? (SQLite >= 3.7 förmodas)

Borde möjlighet att exekvera Disgen i 'read-only' läge finnas?

Inser inte riktigt hur det skulle påverka semaforprincipen som sådan, det gör det väl knappast? Men om du menar att Disgen borde klara samtidiga användare så är det rätt många andra saker i koden som effektivt förhindrar detta, i alla fall i dagsläget. Det är i alla fall inte något som enbart kan lösas på databasnivån.

Det finns möjlighet att köra disgen readonly men det fungerar bara nästan. Om man in den situationen jag nämnde väljer att inte bryta låset så hamnar Disgen i readonly-läge men man får vara beredd på en och annan krasch. Det ska vi nog kunna reparera med tiden.

Även 8.2 fanns faktiskt i en särskild läsversion, men den fick aldrig någon spridning. Där var alla spärrar gjorda i användargränssnittet och resultatet blev inte så värst bra.

För att den aktuella semaforprincipen skulle ha varit säker, hade läsning och skrivning av tabellraden behövt vara en atomär operation (jämför 'Compare-and-swap' eller 'Test-and-set').

Å andra sidan används ju Disgen inte - som tur är - i några säkerhetskritiska sammanhang.

Säkerhetskritisk släktforskning, ja det hade ju varit något.

Nu finns det i och för sig ytterligare lås som förhindrar att två instanser av Disgen öppnar samma datamapp, och där används existensen av en namnad mutex som lås. Det blir vattentätt så länge man är på samma maskin. Jag tror dessa mekanismer tillsammans blir tillräckligt bra i förhållande till vad vi vill uppnå...