Error Establishing DB Connection

[/nextpage]

 

Nogle har også foreslået, at de løste deres problem ved at erstatte localhost med IP. Det er almindeligt at se denne type problem, når du kører WordPress på et lokalt servermiljø. For eksempel på MAMP kan DB_Host-værdien, når den ændres til IP’en, synes at virke.
1

define ('DB_HOST', '127.0.0.1:8889');

 

Bemærk at IP’erne vil variere for online web hosting-tjenester.

 

Hvis alt i denne fil er korrekt (sørg for at kontrollere efter typografier), så er det rimeligt at sige at der er noget galt på serverens ende.Tjek din webhost (MySQL Server)

Ofte vil du bemærke denne fejl ved oprettelse af databaseforbindelse, når dit websted bliver belastet med en masse trafik. Dybest set kan din værtsserver ikke håndtere belastningen (specielt når du er på delt hosting). Dit websted bliver meget langsomt, og for nogle brugere får du selv fejlen. Så det bedste du kan gøre er at komme i kontakt eller livechat med din hostingudbyder og spørge dem, om din MySQL-server er belastet.

For de brugere, der vil teste, om MySQL-serveren kører selv, kan du lave et par ting. Test andre websteder på den samme server for at se, om de har problemet. Hvis de også får den samme fejl, så er der helt sikkert noget galt med din MySQL-server. Hvis du ikke har noget andet websted på denne samme hosting-konto, skal du blot gå til din adminpanel hos udbyder og prøve at få adgang til phpMyAdmin og forbinde databasen. Hvis du kan oprette forbindelse, skal vi kontrollere, om din databasebruger har tilstrækkelig tilladelse. Opret en ny fil kaldet testconnection.php og indsæt følgende kode i den:
1

<?php
$link = mysql_connect('localhost', 'root', 'password');
if (!$link) {
die('Could not connect: ' . mysql_error());
}
echo 'Connected successfully';
mysql_close($link);
?>

 

Sørg for at erstatte brugernavnet og adgangskoden med dine egne. Hvis forbindelsen lykkes, betyder det, at din bruger har tilstrækkelig tilladelse, og der er noget andet der er forkert. Gå tilbage til din wp-config fil for at sikre, at alt der er korrekt (genskan efter typografier). Hvis du ikke kan oprette forbindelse til databasen ved at gå til phpMyAdmin, så ved du, at det er noget med din server. Det betyder ikke nødvendigvis, at din MySQL-server er nede. Det kan betyde, at din bruger ikke har tilstrækkelig tilladelse.

I mit tilfælde kørte mins MySQL-server. Alle andre websteder på serverne fungerede fint bortset fra grandts.com. Da jeg forsøgte at gå til vores phpMyAdmin, endte jeg med at få fejlen:

# 1045 – Adgang nægtet for bruger ‘foo’ @ ‘%’ (bruger adgangskode: JA)

Jeg kontaktede Gigahost, og deres support fandt hurtigt problemet. På en eller anden måde blev vores brugers tilladelser nulstillet. Ikke sikker på, hvordan det skete, men det var tilsyneladende årsagen. De gik tilbage og gendannede tilladelserne, og vi kunne få webstedet tilbage live. Så hvis du bliver nægtet adgangen til enten at forbinde til phpMyAdmin eller gennem testconnection.php resultater, skal du straks kontakte din udbyder for at få dem til at rette op på dette.

Løsninger, der virkede for andre

Det er vigtigt at bemærke, at disse måske ikke virker for dig. Brug på egen risiko, og sørg for, at du har tilstrækkelige sikkerhedskopier, hvis noget går galt. Hans Jansen sagde, at hans klient fik fejlen, at databasen skal repareres. Selv efter at have repareret databasen, gik fejlen ikke væk. Han forsøgte forskellige ting og i sidste ende var spørgsmålet webstedets url. Tilsyneladende blev det ændret, hvilket fik fejlen til at fortsætte. Han kørte SQL-forespørgslen ved at gå til phpMyAdmin:
1

UPDATE wp_options SET option_value = 'YOUR_SITE_URL' hvor option_name = 'siteurl'

 

Sørg for at erstatte YOUR_SITE_URL med det egentlige url-eksempel: http://www.grandts.com. Wp_options vil være anderledes, hvis du har ændret standard WordPress database præfiks.

Dette syntes at løse problemet for ham og få andre, der kommenterede hans indlæg også. Jen Madsen foreslog, at han kunne forbinde databasen med testconnection.php, så han ændrede wp-config.php-brugeren til root-brugeren. WordPress begyndte at fungere helt fint. Derefter vendte han indstillingerne tilbage til databasebrugeren, og det fortsatte med at fungere. Han kunne ikke finde ud af, hvad der var galt, men konkluderede, at det var en skrivefejl. Jeg ha desudne læst om adskillige kilder, at brugerne simpelthen uploadede en ny kopi af WordPress, og det fik fejlen til at forsvinde.

 
0 replies

Skriv en kommentar

Want to join the discussion?
Feel free to contribute!

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *