Fix Error Establishing Database Connection

Error Establishing Database Connection. Hvis du har surfet på internettet i et stykke tid, har du i det mindste set denne fejl et par gange. Fejl ved oprettelse af en databaseforbindelse er en af ​​de forbandelser, der kan skyldes mange grunde. Som en WordPress-nybegynder kunne det være meget frustrerende specielt, når det skete på egen hånd uden at ændre noget. Vi løb ind i dette problem i går på vores eget websted.

Det tog lidt over 20 minutter at opdage og løse problemet. Mens vi gjorde forskningen for at finde mulige årsager, indså vi, at der ikke var nogen god artikel, der dækkede alt. I denne artikel vil vi vise dig, hvordan du løser fejlen ved oprettelse af en databaseforbindelse i WordPress ved at kompilere en liste over løsninger på ét sted.

Bemærk:

Før du foretager ændringer i databasen, skal du sørge for at have tilstrækkelige sikkerhedskopier.

Hvorfor får du denne fejl?

Kort sagt, du får denne fejl, fordi WordPress ikke kan oprette en databaseforbindelse. Nu er årsagen til, at WordPress ikke kan oprette en databaseforbindelse, forskellige. Det kan være, at din database login credentials er forkert eller er blevet ændret. Det kan være, at din databaseserver ikke reagerer. Det kan være, at din database er blevet beskadiget. I vores erfaring sker størstedelen af ​​gange denne fejl på grund af en slags serverfejl, men der kan også være andre faktorer. Lad os se nærmere på, hvordan man skal løse problemet med dette problem.

Opstår problemet for / wp-admin / også?

Første ting du skal gøre er at sikre, at du får den samme fejl på både forsiden af siden og bagenden af webstedet (wp-admin). Hvis fejlmeddelelsen er den samme på begge sider “Fejl ved oprettelse af en databaseforbindelse”, skal du fortsætte til næste trin. Hvis du får en anden fejl på wp-admin f.eks. Som “En eller flere database tabeller er ikke tilgængelige. Databasen skal muligvis repareres “, så skal du reparere din database.

Du kan gøre dette ved at tilføje følgende linje i din wp-config.php-fil. Tilføj det lige før ‘That’s all, stop editing! Happy blogging’ linje i wp-config.php.
1

define ('WP_ALLOW_REPAIR', true);

Når du har gjort det, kan du se indstillingerne ved at besøge denne side: http://www.dinside.dk/wp-admin/maint/repair.php
Men husk du SKAL indsætte koden herover i din wp-config.php først! ellers får du et skærmbilleder som herunder:

[nextpage title=”Næste Side”]

Husk, at brugeren ikke skal logge ind for at få adgang til denne funktionalitet, når denne definition er indstillet. Dette skyldes, at hovedformålet er at reparere en beskadiget database. Brugere kan ofte ikke logge ind, når databasen er korrupt. Så når du er færdig med at reparere og optimere din database, skal du sørge for at fjerne dette fra din wp-config.php.

Hvis denne reparation ikke løste problemet, eller hvis du har problemer med at køre reparationen, så fortsæt med at læse denne artikel, da du måske kan finde en anden løsning der fungerer.

Kontrol af WP-Config-filen

WP-Config.php er nok den enkelt vigtigste fil i hele din WordPress-installation. Her angiver du detaljerne for WordPress til at forbinde din database. Hvis du har ændret din rodadgangskode eller databasens brugeradgangskode, skal du også ændre denne fil. Første ting du altid skal kontrollere er, om alt i din wp-config.php-fil er det samme.
1
2
3
4

define ('DB_NAME', 'database-navn');
define ('DB_USER', 'database-brugernavn');
define ('DB_PASSWORD', 'database-password');
define ('DB_HOST', 'localhost');

Husk, at din DB_Host-værdi måske ikke altid er localhost. Afhængigt af værten vil det være anderledes. Som eksempel er gigahost.dk en af de der anvender f. eks
mysql1.gigahost.dk

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_main_siteoptions SET option_value = 'YOUR_SITE_URL' hvor option_name = 'siteurl'

Sørg for at erstatte YOUR_SITE_URL med det egentlige url-eksempel: http://support.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.