Sommaren 2006 fick jag ett sommarjobb efter många år som dessutom betalade bra. Bestämde mig direkt för att köpa en ny dator efter många år. Jag passade då också på att gå över till GNU/Linux och valde att testa Kubuntu. Fastnade för det direkt och har sedan dess bara använt Windows XP i skolan och på jobbet. Oftast för att bara för att använda internet eller skriva arbeten och rapporter. Men sedan vi startade Cperspective så har behovet av att använda Windows ökat. Mest på grund av att Adobes produkter inte finns till GNU/Linux och min dator hunnit bli för gammal för att hantera flera system plus Adobes tunga produkter.

Nyligen fick jag ta över en bärbar dator efter att en kollega slutat på företaget och nu är jag tillbaka på Windows. Windows Vista kan det tilläggas. Och efter några dagars användande så kan jag direkt konstantera att jag inte har missat något. Ubuntu är helt klart ikapp och förbi Windows Vista i användarvänlighet. De ända två områdena Windows är bättre GNU/Linux på är att det har fullt stöd från alla stora och viktiga tredjepartsutvecklare (inklusive spelutvecklarna) och att installation av program är mer konsekvent i Windows än i GNU/Linux.

Nu ska jag forsätta återanpassningen till Windows och Vista…

Ändra förinställd teckenkodning

August 13th, 2009 | Posted by admin in Server - (0 Comments)

Ett annat problem vi hade med den nya sidan vi köpt var teckenkodningen på sidan. Teckenkodningen kan sättas både i HTTP-headern och i utvecklingsfilerna. Om teckenkodningen är satt på båda ställen så är det teckenkodningen i HTTP-headern som kommer användas av webbläsare. I vårt fall är teckenkodningen i HTTP-headern satt till UTF-8 men sidan använder ISO-8859-1. Denna konflikt ledde i slutändan till att bokstäverna åäö ersattes med nonsenstecken.

Men om man har tillgång till .htaccess filen så finns det ett enkelt sätt att komma runt det förinställda värdet i HTTP-headern. Allt man behöver göra är att lägga in följande i .htaccess-filen så kommer HTTP-headern att sättas till önskad teckenkodning:

AddDefaultCharset ISO-8859-1

SQLyog – En räddare i nöden

August 13th, 2009 | Posted by admin in Databas - (0 Comments)

Vi köpte nyligen en hemsida med en databas på 2,7 GB. Men som de flesta känner till så har phpMyAdmin, genom inställningar i php, en begränsning på att bara kunna importera filstorlekar på max 2 MB. Samtidigt saknar vi tillgång till ssh för att ansluta till vårt webbhotell.

Hade det varit en mindre databas hade det inte varit något problem att öppna .sql-filen i en textredigerare och sedan kopiera innehållet och klistra in det i phpMyAdmin. Men en fil på 2,7 GB går inte ens att öppna i textredigerare.

Supporten på vårt webbhotell sa att vi hade två alternativ. För det första kunde vi använda ett databashanteringsprogram som Navicat eller så kunde vi ge dem sql-dumpen och databasuppgifterna så kunde de importera databasen. Av tidigare erfarenhet ville jag undvika det andra alternativet eftersom att deras hantering av sql-filer av någon anledning förstör åäö-bokstäverna i databaser. Så jag provade Navicat som svarade med att krascha så fort jag klickade på importera knappen.

Jag blev istället rekommenderad php-skriptet BigDump som skapats just för att importera stora sql filer. BigDump fungerar genom att det laddar in mindre bitar av databasen i taget och stänger därimellan ner sig själv och startar om igen där den senast avslutade. På så sätt är det tänkt att unvika många av de problem som uppstår i situationer som dessa då till exempel ett skript som körs under lång tid kan stängas ner beroende på de inställningar man har på sin server. BigDump är väldigt enkel att använda. Det enda man i princip behöver göra är att ladda upp den enda fil skriptet består av och även ladda upp sin sql-dump. Sedan navigerar man till filen och väljer att starta importen av filen. Skriptet verkade fungera till en början men avbröts efter cirka två minuter. När jag kontrollerade i phpMyAdmin så hade bara sex tabeller av 25 importerats.

Här var jag på gränsen att ge upp när en av mina kollegor efter ännu ett snack med supporten rekommenderade SQLyog som är ett annat databashanteringsprogram. Jag var skeptisk men hade inte direkt något att förlora. Till skillnad från Navicat har SQLyog en community version av sitt program (som alltså är gratis) och är dessutom mycket mer intiutiv och klarar även av att importera sql-dumpar, vilket Navicat inte gör. Det tog ungefär fem minuter att ladda ner SQLyog och starta importen (där det mesta av tiden gick åt att hitta och skriva in databasuppgifterna) och visst klarade SQLyog av uppgiften. Väldigt elegant faktiskt, även om det tog tio timmar.

main data tab

Minst sagt en räddare i nöden. Programmet verkar så bra att jag nog kommer börja använda det för andra databas relaterade uppgifter också. Rekommenderar definitivt det programmet till alla som vill importera stora sql-dumpar.