Har en accessdatabas som är på 23MB! Körde lite delete-funktioner och raderade sisådär 30 000 poster. När jag uppdaterar listan i mitt ftp-program säger den fortfarande att databasen är 23MB! Vad göra?
Lagrar den raderade poster i nån slags temporär osynlig trashtabell i databasen? Hur tömmer man den i så fall?
Jag kan nämlien inte ladda ner och ändra i databasen själv då MS Access inte finns till mac som bekant.
Tack!
Mvh,
R// Ja, det finns ett Access-forum men min fundering är om jag via ASP kan tömma databasen?
Och varför Access? Jadu, ung och dum ;) Nån som kan säga hur jag på ett smidigt sätt ska få över 23MB till mysql utan MS Access? Någon smidig ASP-lösning till och med? :D
Reparera / Komprimera gör hela jobbet
Om du inte har tillgång till det kanske du kan ta och importera samt Exportera.
Skall inte vara några problem Jag tror att ver 2002 och senare gör vissa sådana saker med automatik.
Access har, enligt vad jag vet, den lilla egenheten att inte radera rader, utan snarare inaktivera raden det handlar om. Det är antagligen därför din databas inte minskar i storlek.
Jag har varit med om exakt samma sak, och med risk för att låta tjatig; komprimera / reparera databasen.
Access har, enligt vad jag vet, den lilla egenheten
Nån egenhet för Access är det väl knappast? Den databas som började skyffla X MB ett steg åt vänster därför att man plockade bort byte nummer 1 skulle ju få svarstider som inte liknade nånting.
SQL Server uppför sig på exakt samma sätt (förutom att det finns bättre möjligheter att schemalägga komprimeringar/shrinks).
Reparera / Komprimera gör hela jobbet
Om du inte har tillgång till det kanske du kan ta och importera samt Exportera.
Skall inte vara några problem Jag tror att ver 2002 och senare gör vissa sådana saker med automatik.
Ok, tack för svaren.
Om jag inte har tillgång till? MS Access? Så ska jag importera och exportera med? Version 2002 av vad? :)
Du kan ju komma åt data med flera typer av verktyg.
Det finns ju typ AQT eller Dbmgr2 som borde kunna hantera detta.
Alternativ är ju som någon skrev zippa hem den och låt någon köra komprimering. Hör av dig om du inte finner någon i närheten.
Access har, enligt vad jag vet, den lilla egenheten
Nån egenhet för Access är det väl knappast? Den databas som började skyffla X MB ett steg åt vänster därför att man plockade bort byte nummer 1 skulle ju få svarstider som inte liknade nånting.
Som sagt, jag har ingen aning om hur en DBMS (eller Access) kärnfunktioner fungerar, så det vet nog du bäst. Jag vidhåller dock att det förefaller sig ganska underligt att den behåller sin storlek, hela tiden. Därav uttrycket 'egenhet', som jag tycker passar ganska bra, eftersom det resulterar i det fenomen som diskuteras.
Rensas dessa rader efter ett tag? Finns det någon lösning, programmatiskt, att lösa en komprimering?
Jag vidhåller dock att det förefaller sig ganska underligt att den behåller sin storlek
Och jag vidhåller att det inte är underligt eller specifikt för Access om man tänker på två saker:
1. Databaser växer ofta, men krymper sällan.
2. Folk förväntar sig att databaser ska vara snabba.
Om vi tänker oss att du har en databas på X Gig och via en UPDATE ändrar 'pelle' till 'per' så har databasmotorn två val:
A. Sätta igång som en vettvilling och skyffla/packa data fram och tillbaka för att du ska tjäna 4(!) bytes diskutrymme.
B. Behålla diskallokeringen och bara ändra längdmarkeringen på datan och iskallt räkna med att du (eller nån annan) för eller senare kanske ändrar tillbaka till 'pelle' (eller nåt ännu längre).
Taktik B är nog det som används av de flesta databaser oftast (finns säkert undantag i olika sammanhang).
OveRRidE skrev:
Rensas dessa rader efter ett tag? Finns det någon lösning, programmatiskt, att lösa en komprimering?
Ja, det flesta databaser har ju just separata funktioner för komprimering av den anledningen att det är bättre krympa mycket men sällan, än att krympa lite men ofta. Desa funktioner går väl sen i allmänhet att komma åt programmatiskt om man vill det.
Det jag menade var dock att jag tycker att Access borde ha sin 'komprimerings'-runda lite oftare än.. låt säga aldrig, som jag upplever det i vissa fall i dagsläget.
Extra frågor; ponera dessa två händelser i databasen med förutsättningen att tabellen 'qwerty' innehåller 5000 rader med ganska lika mängd data på varje rad.
1. En DELETE på alla rader i 'qwerty' körs.
2. En INSERT med 5000 nya rader i 'qwerty' körs.
Gäller samma princip då också?
RED. Tilläggsfråga; Om jag kör DROP på en tabell full med data och sedan skapar en identisk tom tabell, hur ser det ut då?
Tack ska kolla in det som stod i länken sen. Undrar om webbhotellet har stöd för det.
Anledningen till att jag inte vill skicka iväg databasen till någon är för att det finns en mängd personuppgifter i den och hur mycket man än litar på någon så känns det fel. Dessutom har jag redan skickat iväg databaser till folk i 2 år nu och känns som att jag vill kunna ändra när jag vill själv trots att jag har mac. Dumt att köra access från början men nu blev det så. Ska se om jag kan få tag på MS Access och köra det via mitt Virtual PC Windows 98. Segt men kanske bästa alternativet ändå.
Det jag menade var dock att jag tycker att Access borde ha sin 'komprimerings'-runda lite oftare än.. låt säga aldrig, som jag upplever det i vissa fall i dagsläget.
Jag vet inte hur det är med nyare access-versioner, men vad jag vet kör inte Access några "komprimerings-rundor" alls av den anledningen att den inte vet hur den kommer att belastas och därför inte kan avgöra när det skulle vara lämpligt att göra det. Det överlåter den till användaren.
OveRRidE skrev:
Extra frågor; ponera dessa två händelser i databasen med förutsättningen att tabellen 'qwerty' innehåller 5000 rader med ganska lika mängd data på varje rad.
1. En DELETE på alla rader i 'qwerty' körs.
2. En INSERT med 5000 nya rader i 'qwerty' körs.
Gäller samma princip då också?
RED. Tilläggsfråga; Om jag kör DROP på en tabell full med data och sedan skapar en identisk tom tabell, hur ser det ut då?
Jag har verkligen ingen aning om hur access (eller nån annan databas) fungerar internt så jag misstänker att du får experimentera. Det enda man kan säga är att de flesta kanske använder principer som:
1. Det är snabbare att förallokera 1 MB en gång (även om man behöver mindre) än att allokera 1 KB 1024 ggr just i det ögonblick man behöver det.
2. Det är snabbare att behålla en redan allokerad struktur därför att man förmodligen kan återanvända den senare, än att riva ner allt och bygga upp på nytt vid varje fråga.
Vad gäller just DROP så säger mig min erfarenhet att du kan droppa samtliga tabeller i en fet SQL Server-databas utan att den fysiska MDF-filen på disk minskar med en enda byte (förrän man gör en manuell "shrink" eller kör nån "Autoshrink").
Jag fick ta hela sökvägen dock. Hur skriver man om det till direkt sökväg nu igen?
Körde filen i webbläsaren och det tog ett ganska bra tag :) Eller den gav ett fel efter typ 5min. Men databasen blev från 23MB till 9MB och jag märker inget fel på nya databasen trots webbläsarens fel så allt är väl frid och fröjd :D
