Få Xampp, MySQL och Codeigniter att fungera ihop

August 9th, 2014 | Posted by admin in Databas | How-to | Webbutveckling - (0 Comments)

Har man Xampp och Codeigniter installer lokalt på sin dator så är det inte helt uppenbart hur man ansluter från Codeigniter till MySQL-databasen.

För det första om Apache lyssnar på port 80 så ligger phpMyAdmin på adressen http://localhost/phpmyadmin. Om den lyssnar på vilken annan port som helst måste man skriva in det portnumret. Alltså: http://localhost:xxxx/phpmyadmin. Vilken port Apache lyssnar på hittar man i httpd.conf-filen.

För det andra måste man anropa sin databas med en användare som har rättigheter att ansluta till den specifika databasen och som har rättigheter att göra allt annat också. Som standard med Xampp kan man ansluta till sin databas utan vare sig användarnamn eller lösenord. Försöker man anropa sin databas utan användarnamn från Codeigniter får man felmeddelandet Unable to select the specified database, eftersom denna användare inte har rätten att göra något med databasen. Anslut istället med användare root och inget lösenord så kommer det att funka. Användare root har rättigheter att göra vad som helst med databasen.

För det tredje, om Apache lyssnar på annan port än port 80 måste man i Codeigniters database.php-fil ange vilken port MySQL lyssnar på. I vanliga fall är detta 3306.

Så här kan det se ut i Codeigniters database.php-fil som exempel:
$db[‘default’][‘hostname’] = ‘localhost:3306’;
$db[‘default’][‘username’] = ‘root’;
$db[‘default’][‘password’] = ”;
$db[‘default’][‘database’] = ‘min_databas’;
$db[‘default’][‘dbdriver’] = ‘mysql’;

, ,

Teckenhelvete med MySQL och PHP

August 15th, 2012 | Posted by admin in Databas | Tips | Webbutveckling - (0 Comments)

Håller på och kodar på en ny sida (extentor.nu). Stötte på problemet att åäö-teckena visades som ett frågetecken. Jag har stött på problemet förr så jag brukar vara noga inför nya projekt att överallt använda UTF-8. För det här är en av de vanligast förekommande problemen, men ändå mest svårlösta problemen när man håller på med webbutveckling. Problemet kan sitta var som helst i kedjan mellan databasen till webbläsaren. Håller man tungan rätt i mun och kommer ihåg att sätta UTF-8 över allt så ska det inte vara något problem. Men nu fick jag alltså problemet ändå.

Jag startade ett omfattande felsökningsarbete där jag gick igenom hela kedjan från databasen och försäkrade mig att det på alla ställen stod UTF8. Men det löste inte problemet. Så jag började googla på det. Jag fick upp en del bra artiklar om problemet, men alla handlade uteslutande om att man råkat ha latin1 på ett ställe och UTF-8 på nåt annat ställe och hur man i sådana fall skulle kunna lösa problemet. En artikel som förtjänar ett hedersomnämnande är skrivet av hosting företaget Blue Box där de i detalj går igenom problemet och hur man löser det. En annan användbar källa verkar vara phpportalen där många har och har haft detta problem. Här finns en samlingstråd om detta problem. Och moderatorn marabou har skrivit en användbar checklista för vart problemet kan ligga. Men även artikeln från Blue Box och trådarna på phpportalen handlar främst om man att man råkat sätt latin1 på nåt ställe och UTF-8 på nåt annat ställe. Jag hade från början satt UTF-8 överallt och dubbelkollat att jag faktiskt gjort så.

En annan märklig grej var att åäö fungerande normalt på alla sidor förutom på en sida. Så jag började skriva ut åäö på olika sidor för att se var de fungerade och var de inte gjorde det. Denna godtyckliga strategi mynnade ut i att jag hittade problemet. Jag använde php-funktionen substr för att plocka ut en kortare del av kursnamnet och jag antar att substr inte har stöd för UTF-8, eller snarare för multibyte encoding. I php finns det en motsvarande funktion för substr som klarar av multibyte encodings. Den heter mb_substr. När jag använde denna funktion så löste det problemet.

Att det kan vara en php-funktion som inte klarar av multibyte encodings som är problemet är inget man tänker på direkt. Men det kan vara så och jag hoppas på att denna artikel besparar en del utvecklare en del huvudvärk.

, , , , , , , ,

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.

, , ,