Datenbank SQL bei gmx/1und1 wird nicht gefunden
|
|
Wisselsheim |
Geschrieben am 26.02.2018 um 09:31
|
![]() Neuling ![]() Beiträge: 4 Registriert am: 25.02.18 |
Hallo,, ich habe php Fusion 7.02.7 auf meinem WebSpace geladen, bei Aufruf geht es bis zum Schritt 4, dann geben ich die Datenbankinformationen ein und es geht nicht weiter, weder eine Fehlermeldung noch ein Fortgang. Habe ich etwas falsch eingestellt ? Bin etwas verzweifelt, da es meine erste php Fusion Istalllation ist. Grüße und Danke Sven Klausnitzer |
|
|
Ernst74 |
Geschrieben am 26.02.2018 um 19:14
|
![]() Mitglied ![]() Beiträge: 58 Registriert am: 05.09.17 |
Bei 1 und 1 hast du PHP 7.0.22 da musst du das inoffizielle DE Paket für die Installation nehmen. |
|
|
Wisselsheim |
Geschrieben am 28.02.2018 um 19:57
|
![]() Neuling ![]() Beiträge: 4 Registriert am: 25.02.18 |
Hallo, leider geht es noch immer nicht, Schritt 4 hängt, weder eine Meldung, dass die Datenbank nicht gefunden wird, das PW falsch ist etc. Hängt einfach ! die Seite liegt auf http://www.wisselsheim.net Ich habe das inoffizielle Paket von eurer Seite heruntergeladen, da steht aber auch 7.02.07 das von dir genannte 7.0.22 finde ich nicht ! Grüße Sven |
|
|
Ernst74 |
Geschrieben am 01.03.2018 um 08:08
|
![]() Mitglied ![]() Beiträge: 58 Registriert am: 05.09.17 |
PHP ist nicht gleich PHP Fusion. Dann bleibst du bei der Installation hängen, weil dein MySQL Server nicht mit dem birthdate Format klar kommt. Vielleicht sollte man das mal in der setup.php ändern. |
|
|
Wisselsheim |
Geschrieben am 01.03.2018 um 09:04
|
![]() Neuling ![]() Beiträge: 4 Registriert am: 25.02.18 |
Sorry, aber wie mache ich das ? Bin absoluter Anfänger diesbezüglich ! Danke Sven |
|
|
Systemweb |
Geschrieben am 01.03.2018 um 18:13
|
![]() Administrator ![]() Inoffizielles DE Updatepack ![]() Beiträge: 505 Registriert am: 01.07.14 |
Im Inoffiziellen Update ist aber das DB-Feld für Birthdate geändert, daran sollte es also nicht liegen. |
|
|
Wisselsheim |
Geschrieben am 01.03.2018 um 19:16
|
![]() Neuling ![]() Beiträge: 4 Registriert am: 25.02.18 |
Es hängt noch immer bei Schritt 4 Konfiguration der Datenbank :-( Zusammengefügt am 02. März 2018 um 08:14:50: Habe WordPress zum testen installiert, Mit WP funktioniert die Datenbank, wurde imitiert. Bearbeitet von Wisselsheim am 02.03.2018 um 08:14 |
|
|
Systemweb |
Geschrieben am 03.03.2018 um 20:13
|
![]() Administrator ![]() Inoffizielles DE Updatepack ![]() Beiträge: 505 Registriert am: 01.07.14 |
Hast du evtl. Zugriff auf die error.log des Webservers oder kannst du das error_reporting in der php.ini aktivieren? |
|
|
Rolly8-HL |
Geschrieben am 04.03.2018 um 16:40
|
![]() Fusioneer ![]() Beiträge: 1071 Registriert am: 30.10.13 |
Zitat: Systemweb schrieb: Im Inoffiziellen Update ist aber das DB-Feld für Birthdate geändert, daran sollte es also nicht liegen. Wenn ich das aber jetzt mit diesem Eintrag wie dort angegeben ist anwende. Code
Code
Code
Sollte man den nicht doch lieber den Server wechseln? Es sei denn es gibt eine Lösung dafür, für die Ausgabe diesen Monat und Heute Geburtstag. Gruß Rolly8-HL
Was für Andere Wichtig ist muss für mich nicht genauso Wichtig sein! Bin Dickkopf Unbelehrbar mache aus Protest nicht das was andere für Richtig halten! Das gibt einem zu Denken oder? |
|
|
Systemweb |
Geschrieben am 22.03.2018 um 18:19
|
![]() Administrator ![]() Inoffizielles DE Updatepack ![]() Beiträge: 505 Registriert am: 01.07.14 |
@Rolly: Problem ist, dass der default-Wert "0000-00-00" für ein Datenbankfeld vom Typ "date" nicht mehr gültig ist. Genullte Datumsangaben sind damit unzulässig. Ist der Datenbank-Server so eingestellt das "STRICT_MODE" eingeschaltet ist (also striktes Einhalten der Regeln auf "ja") kommt es bereits bei einer Neuinstallation vom originalen PHP-Fusion 7 zu einem Fehler. Sicher kann man raten "Wechsel doch einfach den Server bzw. Anbieter" bzw. "Ändere deine Serverinstellungen", aber das kann nicht die optimale Dauerlösung sein. Null-Angaben beim Datum sind in MySQL nun ungültig, auf STRICT_MODE = off umzustellen ist im Prinzip nur eine Verschleppung dieses Problemes. Das entspräche dem gleichen Prinzip, als wenn man durch ein PHP-Update hervorgerufene PHP-Warnungen oder Fehler mittels Error_Reporting-Direktive unterdrückt, ohne für die nahe Zukunft eine entspr. Anpassung zu planen. Nun könnte man hergehen und den Defaultwert auf ein gültiges Datum setzen, z.B. 1931-01-01. Die Installation klappt damit, aber man kommt zum nächsten Problem: jeder neu registrierte, der sein Geburtsdatum nicht angegeben hat, wird als 87-jähriger angegeben, denn PHP-Fusion geht nur bei genullten Werten von einem noch nicht gesetzten Geburtsdatum aus. Als wirkliche Problemlösung bieten sich 2 Wege an: 1. Fusion beibringen, dass das Datum 1931-01-01 als "nicht angegeben" eingestuft wird und den Defaultwert wie oben ändern. Das wäre aber nur gut bei Neuinstallationen. Bei bereits bestehenden Fusionseiten würden dann Mitglieder auftauchen, die über 2000 Jahre alt sind. Man müsste also ebenfalls 0000-00-00 als "nicht angegeben" bewertet lassen. Manche Infusionen müssten dann ggfs. ebenso angepasst werden. 2. Dem Datenbank-Feld einfach einen anderen Typ zuweisen, damit man weder Fusion noch diverse Infusionen (die auch aufs Geburtsdatum zurückgreifen) umbauen muss. Hierbei muss aber sichergestellt sein, dass stets korrekte Werte im Datumsformat in diesem Feld gespeichert werden. Setzt man also den Typ "varchar(10)", kann man weiter damit arbeiten ohne das System umbauen zu müssen. Einzig die Überprüfung durch MySQL auf einen Wert im Datumsformat entfällt, der Datenbank-Server nimmt also theoretisch alle zu speichernden Werte ohne Protest an, z.B. auch "1234567890" oder "abcdefghij", die keinem Datumsformat entsprechen. Da PHP-Fusion die gemachten Angaben im Profil jedoch vor dem Schreiben in die DB selbst auf gültige Eingaben überprüft und das zu speichernde Geburtsdatum korrekt formatiert, kann man das vernachlässigen. Somit sollte Methode 2 angebrachter sein. Deine Codebeispiele funktionieren dabei weiterhin problemlos. Zur Sicherheit habe ich dein 1. Beipiel getestet unter dem Update-Pack 2.0, bei dem ebenfalls varchar(10) gesetzt ist. (Dieser Datums-Fix war aber bereits im Updatepack v1.1 enthalten.) Es wurde ein Panelcode per Vorschau getestet mit folgendem Inhalt: Code
Dein 2. Codebeispiel funktioniert folglich ebenfalls, allerdings ist die von dir gewählte Bedingung "AND !user_status= 1" nicht zu empfehlen, da hierbei auch suspendierte und vor allem auch anonymisierte User dem Suchmuster entsprechen, lediglich deaktivierte werden herausgefiltert. "AND user_status= 0" ist hier zu empfehlen. |
|
|
Rolly8-HL |
Geschrieben am 22.03.2018 um 21:32
|
![]() Fusioneer ![]() Beiträge: 1071 Registriert am: 30.10.13 |
Da ich so einen Server nicht habe um dieses zu testen muss ich hier mal die Frage stellen. Wäre dann eine Installation unter diesen Kriterien mit diesem Eintrag möglich? Code
Wenn ja? dann hat sich meine Frage erledigt, den Rest habe ich dahingehend schon alles angepasst. Gruß Rolly8-HL
Was für Andere Wichtig ist muss für mich nicht genauso Wichtig sein! Bin Dickkopf Unbelehrbar mache aus Protest nicht das was andere für Richtig halten! Das gibt einem zu Denken oder? |
|
|
Systemweb |
Geschrieben am 22.03.2018 um 22:27
|
![]() Administrator ![]() Inoffizielles DE Updatepack ![]() Beiträge: 505 Registriert am: 01.07.14 |
Meines Wissens sollten alle Datums/-Zeitangaben in MySQL ab 1000-01-01 00:00:00 akzeptiert werden. |
|
Springe ins Forum: |