habe den fehler erst nach einspielen des lizenzschlüssels für ptv5 bekommen. mit 5.50.3 hatte das nichts zu tun bei mir.
kann den fehler auch nicht mehr aufrufen. habe einen screenshot davon gemacht

aber PVS-mäßig (solutio charly 9.28.1) läuft fast alles gut, selbst nach dem datenbank-upgrade 8.4.6 => 9.5 => 13.12 außer kim-versenden (empfang läuft gut wie immer) und somit kein eHKP/eBZ und auch das neue ePA-modul will nicht.
die postgres13er datenbank ist auch schlanker als der 8.4er kloß aus dem vorherigen jahrzehnt, wahrscheinlich konnten voluminösen tabellen nicht übertragen werden. hauptsache die behandlungsblätter sind vollständig.
evtl. noch 13.12 => 16 aber erstmal smtp-kim und epa
wäre nett, wenn sich charly-endnutzer melden bei der frage: war das so geplant, dass jüngere datenbanken (bspw. aus dem e-modul) nicht mitkonvertiert werden? habt ihr eure alten kim-nachrichten? könnte ihr alte ebz-nachrichten öffnen.

übrigens, meine Meinung zum begriff FATAL

Zitat von Junioruser1976 im Beitrag #5

---

Zitat von rfkoem im Beitrag #3

---

wäre nett, wenn sich charly-endnutzer melden bei der frage: war das so geplant, dass jüngere datenbanken (bspw. aus dem e-modul) nicht mitkonvertiert werden? habt ihr eure alten kim-nachrichten? könnte ihr alte ebz-nachrichten öffnen.

---

also ich hab von 9.x auf 13.1 Anfang Oktober umgezogen- und bei mir ist alles da ..auch die alten Nachrichten usw. .und Kim läuft ein- und ausgeghend

Zitat von rfkoem im Beitrag #3

---

wahrscheinlich konnten voluminösen tabellen nicht übertragen werden.

---

backup rücksichern von vor Migration manuell rücksichern in die bestehenden ehealth db? vielleicht kriegt man dann das verlorene noch wieder... ? allerdings keine Ahnung, ob ein backup von 8.X oder 9.X für pg13 kompatibel wäre... - notfalls wäre ja auch die alte Instanz noch da, soweit ich sehe, wurde die ja nicht bei Migration gelöscht- und zumindest einsehen könnte man die alten daten nochmal ,z.B. wenn man außerhalb Praxisbetrieb mal den neuen postgres Dienst nochmal wieder deaktiviert und alten postgresdienst reaktiviert ...

welches .bat war es _migrate solutio oder migrate_all?

Zitat von rfkoem im Beitrag #3

---

13.12 außer kim-versenden (empfang läuft gut wie immer) und somit kein eHKP/eBZ und auch das neue ePA-modul will nicht.

---

ePA- PA HKP Modul oder Upgrade ePa = elektronische Patientenakte von 1.X auf 2.5 ? Bei letzterer funktioniert bei mir seit dem upgrade 9.28.2 das Upload von Bildern nicht mehr, da krieg ich Fehler....

Bzgl. SMCB/ausgehend KIM geht nicht mehr- Was sagt der Gegentest: Thunderbird + Kim Client Modul: läuft da alles, nur charly + KIM Client Modul läuft nicht mehr?

Wenn das so sein sollte: was sagen denn webapp log KIM und ehealth log Charly ? Signatur EHKP klappt noch- es steigt danach dann aus mit "Senden fehlgeschlagen" im KIM ? Ist in den Tables eHKP und eAU ... mit pgadmin überall die richtige und aktuelle SMC-B Nummer? (vielleicht hat bei der Migration irgendein Restdatenbestand alte SMC-B überlebt oder wurde wiederbelebt- hab hier bis heute auch noch bei Teilfunktionen die alte SMC-B mit im Rennen z.B. bei eAU oder eHKPs- er bietet mir immer noch auch die alte SMC-B parallel mit der neuen an...)

Zitat von rfkoem im Beitrag #3

---

13.12 => 16 aber e

---

will Solutio nochmal raufziehen auf diese Version? gab es hierzu schon inoffzielle Informationen intern?

---

call "%installer_path%" --superaccount postgres13 --superpassword %pg13_superuser_password% --prefix "%pg13_path%" --datadir "%pg13_path%\data" --servicename %pg_service_name% --enable_acledit 1 --disable-components pgAdmin,stackbuilder --mode unattended --unattendedmodeui minimalWithDialogs
 

--disable-components pgAdmin? wozu denn? haben Sie @Junioruser1976 pgAdmin 4 in postgres13? selbst im letzten developer-call konnte mir keiner antworten, warum auf pgAdmin 4 verzichtet wird. entwickeln programmierer und vorstand unabhängig voneinander?. smc-b stimmt. alte smc-b musste raus und platz machen für neue smc-b. sonst ging das einlesen der karten nicht mehr.

ich würde am liebsten es einfach so lassen wie es ist. mir sind die aufbewahrungsfristen völlig egal geworden https://www.iww.de/zp/praxismanagement/h...was-gilt-f86105

das upgrade auf postgres 16 wird nicht empfohlen. https://www.facebook.com/groups/68753036...764228760383747

BUJA CHAKA!

inzwischen weiß jeder, dass ich so geupdated habe => 8.4.6 => 9.5.25 => 13.12, habe also das migrate_all.bat skript auch am dateinamen geändert, dateinamen, der zu runterladenen installationsdatei. ist halt auch ein update, sicher ist sicher. https://pastebin.com/5jbXrW88

eins vorweg: upgrade von 8.4.6 zu 13 geht NICHT!

zumindest hatte ich nach 6 stunden von 8 auf 13 direkt keine geduld mehr. 8.4.6 zu 9.5 waren 2 stunden und 9.5 zu 13.12 waren 3 stunden. nach 60 % der zeit war ein kern von 4 stark ausgelastet und die festplatte (ja leider noch festplatten) war kaum belastet.

unter den windows diensten gibt es einen postgres dienst der heißt postgresql-x64-9.5. ich habe für diesen versuch die charly dienste beendet, dann die postgres13 beendet als dienst und den dienst der postgresql-x64-9.5 gestartet. alles ist da! ALLES!

ich gebe nicht solutio oder dem skript die schuld, irgendwie ist die migration zu postgres13 für mich nicht einfach.

es wurden bei versuch gestern mit der postgres8 und heute eben mir der postgres9.5 die neusten kim-nachrichter runtergeladen weswegen auch mehr eHKP als genehmigt markiert sind. bei postgres 13 fehlen die ebz-antragsnummern. es kommen genehmigungen an (POP3 geht also bei postgres13) aber charly weiß nicht, zu welchen patienten das gehört.

ich würde am liebsten bei postgres13 bleiben und sozusagen von null anfangen bei allem was mit ehealth zutun hat, wenn kim SMTP wieder geht.

was ich machen könnte: von postgres8 auf 13.11 wechseln auf meinem weg und DANN das skript benutzen. aber ich denke, das ergebnis würde sich nicht ändern.

noch krasser wäre 8 => 9 => 10 => 11 => 12 => skript => 13

Es ist in der Tat so, dass meine Methode wesentlich besser funktioniert.
dump erstellen => cmd im bin-Verzeichnis der älteren postgres-Version => pg_dumpall -U postgres -f E:\Solutio\dumpVERSIONSNUMMER-DATUM.sql
21 Mal das Passwort #XXXXXXXXXXXXX eingeben
alten postgres-Dienst beenden, neues postgres im separaten Ordner installieren => cmd => call postgresql-16.0-1-windows-x64.exe --superaccount postgres16 --superpassword #post.2000! --prefix E:\Solutio\Server\PostgreSQL16 --datadir E:\Solutio\Server\PostgreSQL16\data --servicename Solutio-PostgreSQL16
dump einspielen => cmd im bin-Verzeichnis der neuen postgres-Version => psql -U postgres16 -d postgres -f E:\Solutio\dumpVERSIONSNUMMER-DATUM.sql
Ein Mal das Passwot #XXXXXXXXXXXXX eingeben.
habe nacheinander postgres9.5 und postgres16 genutzt und charly gestartet. Es ist alles da. Alles. und nun? (19.10.2023)

Eine Sache ist neu beim Start der charly-internen Sicherung: Fehler in ppg-Service beim Sichern der Datenbanken. Tritt bei Postgres16 auf.

lösung:

https://imgur.com/a/mXnV89K

https://pastebin.com/5jbXrW88
https://www.pg-forum.de/t/postgresql-13-...rver-2012/12835
https://www.pg-forum.de/t/datenbanken-verschmelzen/12881