pragmaMx Support Forum

Hallo,
ich möchte demnächst zu einem anderen Webhoster wechseln.
Bei dem Umzug würde ich aber gerne mit dem wenigsten Aufwand das System mit dem kompletten Datenbestand wiederherstellen.
Das stelle ich mir so vor:
1. Arbeiten auf altem System
1.1. Sichern und download der kompletten Datenbank
1.2. Download des kompletten Pragmamx

2. Arbeiten auf neuem Host
2.1 Upload der unter 1.2 erhaltenen Daten
2.2 Erstellen der Datenbank mit phpMyAdmin mit den Daten aus 1.1

Und nun das Problem: Da sich mit Sicherheit die Datenbanknamen ändern werden muss ja unbedingt der Installationsvorgang nochmals gestartet werden...

Kann ich das so machen? Werden die Datenbanken dabei nicht überschrieben? ???

Wenn ich zuerst den Installationsvorgang durchziehe und dann die DantenbanKen neu Lade bringe ich doch bestimmt was durcheinander, oder?

Oder bleibt mir vielleicht nichts anderes übrig, als das System "wirklich" neu zu installieren? Kann ich dann einzelne Datenbanken neu Laden? Und welche darf ich auf keinen Fall mit den alten Daten überschreiben?

Gruß xidefix

Hi!

Wenn du ein Backup der Daten und der Datenbank hast, musst die mal auf den neuen Host raufladen.
Wenn du das hast musst nur mehr in der config.php die Daten anpassen.
Also normalerweisse klappt das so und du musst keine neue Installation machen.

L.g

Hallo,
bin gestern mit meinem System umgezogen. Hätte nicht gedacht, dass ds so schnell gehen kann.
Natürlich sind die Domains noch nicht umgeleitet. Ich habe aber eine Umleitung der Domain bei meinem "alten" Webhoster auf eine vorläufig nutzbare Domain eingeschaltet.

Das Funktioniert auch soweit. Aber:
Wenn man sich anmelden will (egal ob als Benutzer oder als Admin), funktioniert das nicht. Die Fehlermeldung lautet:


Nutze ich aber die vom neuen Webhoster mitgeteilte vorläufige Domain, so funktioniert alles wunderbar.

Nein, das ist auch nicht richtig. Wenn ich im Adminmenü die Einstellungen abspeichern will erscheint folgende Meldung:

Nun könnte ich zwar den schreibschutz per FTP ändern, aber das ist nicht im Sinne des Erfinders.

Ich wäre schon froh, wenn es zumindest eine Erklärung für das Problem gäbe.

Übrigens: Vielen Dank an munzur, die Antwort von Dir hat mir geholfen...

Das Problem mit dem anmelden könnte sich ggf. von selbst lösen, wenn die Domains endgültig umgeschaltet werden.
Das mit der config beunruhigt mich etwas mehr. Oder kann ich irgendwo irgend etwas einstellen, was ich vor lauter Betriebsblindheit nicht erkenne?

Gruß
xidefix

Zitat
Nun könnte ich zwar den schreibschutz per FTP ändern, aber das ist nicht im Sinne des Erfinders.

?? Warum ist das nicht im Sinne des Erfinders...es ist im Sinne des Erfinders :D

Zitat von: xidefix am 25 November 2005, 09:53:07

Die Einstellungen konnten nicht gespeichert werden!
Wahrscheinlich konnte der Schreibschutz nicht aufgehoben werden. (config.php)

Nun könnte ich zwar den schreibschutz per FTP ändern, aber das ist nicht im Sinne des Erfinders.
Das mit der config beunruhigt mich etwas mehr.

Moin!
Bei manchen Providern ist es nötig das die config.php CHMOD 777 hat um Änderungen speichern zu können. Das hatte ich auch nach meinem Umzug. Da wirst du nicht drum herum kommen. Wenn du was an den Einstellungen ändern mußt, wirst du vorher die Rechte der config.php auf 777 einstellen müssen.

Gruß, Marcus

Hallo,
und Danke für die Antworten.

Wenn es so ist, dann ist es halt so.

Kann denn jemand was zu dem Anmeldeproblem sagen. Eine Bestätigung meiner Vermutung das sich diese Problem nach der offiziellen Domainübernahme von selbst erledigt, würde mich beruhigen...

Gruß
xidefix

Moin :)

ZitatDie Sessioninitialisierung ist fehlgeschlagen.
Vermutlich verhindern Ihre Sicherheitseinstellungen das Setzen von Cookies. (4)

Die 4 in der Klammer bedeutet, dass beim Login entweder der Username nicht eingegeben wurde, der Username falsch ist, oder dass die Gross-Kleinschreibung des Usernamens nicht stimmt.

Hallo Andi,
ich hatte das Problem "umgangen?", denn ich habe die Foren nochmals durchsucht und bin dabei auf einen Tipp von Dir gekommen der besagt, den Wert 
$mxConf['vkpIntranet']           = '0' auf den Wert "1" zu setzen.
Das hat geholfen. :thumbup:

Ich habe allerdings keinerlei Erklärung dafür. Ich hoffe nichtsdestotrotz, dass nach der Umschaltung der Domain das Problem weg ist....
Das gleiche Problem trat übrigens auf als ich das System auf meinen Linuxrechner portierte.

Irgendwie scheint mir das System zu "merken" dass es nicht mehr da ist wo es mal war, bzw dass es nicht mehr mit der Original-Domain aufgerufen wird.... :-X

Gruß
xidefix :)

oh, daran hab ich jetzt nicht gedacht, wobei die 4 in Klammer sagt eigentlich was anderes aus...

Oki, Hauptsache es funzt ;)

Das dürfte dann später auch funktionieren, wenn die Domain passt ;)

Zitat...das die config.php CHMOD 777...

Das ist so nicht richtig  ;)

- Dateien benötigen lediglich CHMOD 666 wenn Sie bearbeitbar sein sollen

- Verzeichnise hingegen benötigen CHMOD 777

Mögliche Rechte:

• 0: keine Rechte
• 1: nur ausführen
• 2: nur schreiben
• 3: lesen und schreiben
• 4: nur lesen
• 5: lesen und ausführen
• 6: lesen und schreiben
• 7: lesen, schreiben und ausführen

RtR

Hallo !

Zitat- Dateien benötigen lediglich CHMOD 666 wenn Sie bearbeitbar sein sollen
- Verzeichnise hingegen benötigen CHMOD 777

Pffff, das ist jetzt aber sehr allgemein dargestellt.


MfG
jubilee

Ist zwar schon ein weilchen her.

ZitatHallo Andi,
ich hatte das Problem "umgangen?", denn ich habe die Foren nochmals durchsucht und bin dabei auf einen Tipp von Dir gekommen der besagt, den Wert
$mxConf['vkpIntranet']           = '0' auf den Wert "1"

Wenn man das so löst  ist es dann nicht zu unsicher?

Hi :)

bei xidefix ging es um ein lokales Intranet, bzw. um einen lokalen Testserver.
Da muss es so sein.

Bei dir haben wir ja inzwischen eine andere Ursache festgestellt ;)