Hallo Uwe. Das ist nach Blick auf die Verbrauchsansicht und dem langsamen Ablassen meiner Atemluft, auch sofort ein Gedanke gewesen. Was nun? Schöne Idee von Dir und leider wieder nur mit Zusatzprogramm, Konto, Anmeldung etc. zu erreichen. Danke für die Anregungen und Hinweise. Ich habe bisher vermieden, so etwas zu nutzen und ich sehen auch nur einen Grund, warum eine Schnittstelle zum eigenen Rechner und seiner Festplatte bisher keine Umsetzung fand. Eine solche Verlinkungsmöglichkeit ist in meinen Augen keine große Programmieranstrengung. Aber ich kann mich ja täuschen.

Übrigens traue ich der Verbrauchsanzeige noch nicht. Ich habe fast alle Backups, auch die automatischen, gelöscht und die Anzeige ist gleich geblieben. Vielleicht sollte man vor dem überstürzten Kauf von Datenvolumen noch ein wenig warten, bis sicher ist, dass diese auch korrekt funktioniert. Trotzdem großes Danke für Deine Mühe, wieder mal!, für die Ninox-Gemeinschaft. Mirko

Das klingt alles super, bis auf die extra Kosten. Mich würde interessieren ob man in dem Szenario auch die jpg Kompression anpassen kann, oder ob der Speicherplatz den die Bilder auf Baserow einnehmen egal ist im Bezug auf die Kosten. ( nicht bei jedem Handy ist die bildgröße einstellbar, was heißt trotz kleinem bild schlagen dann schon mal 2 MB pro bild zu buche) allerdings würde ich als kostengründen für unser Vorhaben App (monteure im Außendienst) zu web (Verwaltung in teams) nur einen extra Account hinzu buchen wollen. Das hat zwar in der benutzersteuerung einige Nachteile, jedoch stehen die Kosten sonst im Weg. Allerdings bekomm ich dann auch nur 2 GB hinzu, welch natürlich schnell weg sind. Von der Seite würden sich die von dir genannten Kosten schnell rechnen. 

Hallo UweG,

wenn ich Deinen Beitrag richtig verstanden habe, würde eine lokale Installation von n8n mit einer lokalen Installation von Ninox so zusammenarbeiten, dass mit Ninox erstelle und in der Datenbank gespeicherte Dateien (*.csv, *.pdf, etc.) automatisiert an einem in Netzwerk befindlichen Ordner ausgelagert werden kann, richtig?

UweG OK, danke für Dein Feedback! Ich habe eher daran gedacht, mit n8n eine Funktion zu nutzen, die ich in Ninox schmerzlich vermisse, das automatische Downloaden von Dateien, in der Regel CSV, die Ninox selbst erstellt hat. Diese CSV-Dateien sind bei mir Zahlungsträgerdateien und müssen für den Import in MacGiro in einem speziellen Verzeichnis im Filesystem liegen.

Hi UweG ,

Ich hatte heute unterwegs eine Idee, wie das Laden von Vorschaubildern ganz ohne Datenverbrauch gelingen kann.
Ich habe es geschafft in einem FX-Feld ein Bild per html-Befehl anzuzeigen, dass in meiner Nextcloud liegt. Mit dem html-code lässt sich auch die Anzeigegröße einstellen:

html("<img src=https://nextcloud.digi-tool.de/s/Jyemjwt83N2jrpT/preview width=142 />")

Next Step ist die Vorschau von PDFs!
Das geht gundsätzlich mit diesem Code, aber mit Nextcloud hab ichs noch nicht geschafft...
 

html("<embed src=https://nextcloud.digi-tool.de/s/ZfL8f4zEww9sty4 width=280px  />")

Aber ein direkt verlinktes PDF geht:

Viele Grüße
Ronald

Ich versuche meine Datenbank auch gerade zu verschlanken, da sie durch die Massen an PDF's doch recht aufgebläht ist. Das Auslagern der Dateien auf z.B. pCloud geht über Make/Integromat ohne Probleme. Nur wie schaffe ich es die Datei freizugeben und als Link nach Ninox zurückzugeben um sie von dort aus wieder aufzurufen? Hat da jemand eine Idee?

Ich spreche Dropbox über die Rest API übrigens direkt an... ohne Make, Zapier oder n8n...

Das wäre also - so man denn ein Dropbox Abo hat (die Free Version hat ja nur 2 GB, da hat man nix gewonnen) eine Option. Ich schaue mal, ob es nicht auch andere Hoster gibt mit RestAPI und vllt. 50GB Speicher. Wichtig dabei ist, dass der Dateiupload über URL stattfinden kann.

Lieber UweG,

da ich mich mit dem gleichen Problem einer stetig zunehmenden Datenbankgröße herumplage und im Forum auf diesen Thread gestoßen bin, möchte ich kurz meine Situation skizzieren und danach eine Frage stellen:

a) In konkreten Fall handelt sich um eine ziemlich komplexe medizinische Datenbank (50 Tabellen) in der Public Cloud zur Befunderstellung und Arztbriefschreibung. Zur Befunderstellung existiert eine einzige Tabelle, an die während einer Untersuchung oder Operation erstellte Bilder als Dateianhang angehängt werden können.

b) Nach Import der Dateien als Dateianhang wird ein Button gedrückt, der die Bilder in eine Tabelle namens "Bilder" kopiert und dann alle Dateianhänge löscht.

c) Für jedes neue Bild wird ein neuer Record in der Tabelle Bilder erstellt. Dies löst bei Zapier ein Zap aus, dass die Bilddatei in die Dropbox verschiebt, anschließend das Original löscht und durch einen Download-Link ersetzt.

d) Ein ähnlicher Zap existiert auch für jede neue PDF-Datei.

e) Somit enthält die Datenbank weder Dateianhänge noch gespeicherte Bilder oder PDF-Dateien; alles ist in die Dropbox verlinkt.

f) Bei der Erstellung eines Arztbriefes werden diese Bilder temporär heruntergeladen, in das Dokument eingepflegt und nach Fertigstellung des PDF-Dokuments wieder gelöscht.

Dennoch wächst die Datenbank ständig an und hat seit ihrem Start in den Produktivbetrieb Ende August 2023 bereits eine beachtliche Größe: Erstelle ich ein Backup mit Files, dann beträgt die Größe der heruntergeladenen Datei 688 MB. Das Backup ohne Files ist gerade mal 2,3 MB groß.

Somit ergibt sich meine Frage:

Kann es sein, dass Ninox die importierten Bilddateien irgendwo auf dem Server speichert, obwohl sie clientseitig gelöscht werden?

Für diesen Umstand spricht die Auskunft des Supports, dass man bei Überschreiten der max. Speicherkapazität ein Backup erstellen und herunterladen solle. Dieses wäre nach dem Zurück-Importieren unter Umständen kleiner als die Original-Datenbank.

Falls die Dateien auf dem Server gespeichert werden:

Unter welchen Umständen tritt dieses Phänomen auf und wie kann es vermieden werden?

Herzliche Grüße

Stefan