FastReport-Dateien (.fr3) bei einem Programm mitgeben

[Lemmy]

Zitat:

Zitat von RWarnecke (Beitrag 1113520)

Zitat:

Zitat von Sir Rufo (Beitrag 1113519)

Und wieso nicht einfach als Dateien mitgeben? :gruebel:

Weil ich nicht möchte, dass die Reports geändert werden können und um Fehler zu verhindern, falls ein Anwender mal in den Dateien rumpfuscht.

Soll er. Ist dann halt kostenpflichtiger Support die Originale wieder herzustellen. Ich habe die FR3 auch mal in einer DB ausgeliefert - würde ich derzeit nicht mehr machen bzw. nur noch dann machen wenn es um eine Mehrplatzanwendung geht, wo dann alle wirklich den identischen Ausdruck brauchen.

Grüße

[mkinzler]

Zitat:

Ich habe die FR3 auch mal in einer DB ausgeliefert - würde ich derzeit nicht mehr machen

Darf man fragen warum?

[Guido R.]

Ich sehe das ähnlich wie Sir Rufo.
Die FR3-Datei ist einfach eine XML-Datei, also einfacher Text. Die meisten User können aber mit einer solchen Struktur gar nichts anfangen.
Wenn der User dann meint, trotzdem in den Dateien rumzufingern, soll er auch für die Wiederherstellung zahlen.
Je nachdem, welche Datenbank du verwendest, kann man ja auch dort an den den Reports rumfummeln.
Ich z.B. schreibe die FR3-Dateien in Mediumblob-Felder einer MySQL-Datenbank.
Mit einem einfachen Tool wie SQLYog kann man sich diese XML auch wieder im Klartext anzeigen lassen und auch bearbeiten.
Natürlich bestehen noch andere Möglichkeiten die unversehrtheit Deiner Berichte zu gewährleisten. z.B. kannst Du die Berichte in einer
passwortgeschützten ZIP-Datei mitliefern und den jeweiligen Report bei Bedarf entpacken. (Das ZIP-Paket muss ja auch nicht auf ".ZIP" enden)
Das würde jedenfalls die Pflege vereinfachen, wenn Du selber etwas an den Reports ändern willst.

Gruß
Guido

[Lemmy]

Zitat:

Zitat von mkinzler (Beitrag 1113536)

Zitat:

Ich habe die FR3 auch mal in einer DB ausgeliefert - würde ich derzeit nicht mehr machen

Darf man fragen warum?

das größte Problem sind da kleine Änderungen an den FR3 - entweder müssen diese während der Laufzeit des Programmes gemacht werden, damit die fr3 auch gleich wieder in der DB liegen um die Änderungen zu testen, oder die fr3 müssen dann beim Start nach der Änderung in die DB. Es macht halt alles komplexer.

Eine Debug-WEiche wäre klar eine Lösung (d.h. im Debug-Mode die fr3 von der Platte laden) - nur bin ich mit solchen Weichen-Lösungen sehr vorsichtig.

Wie gesagt - den einzigen Vorteil der DB-Lösung sehe ich in einem Netzwerk wenn z.B. Endanwender die Reports bearbeiten können sollen und diese Änderung dann bei allen Clients wirksam werden soll. Das ist anders (Netzfreigabe usw.) umständlicher bzw. nur vom entsprechenden Systemadmin wirklich zu lösen (Rechtevergabe).

Weiterhin wüsste ich jetzt im Moment nicht wirklich wie Report-Vererbung in diesen Fällen eingesetzt werden soll, da hier ja auf eine gespeicherte Datei zurück gegriffen wird. Möglich dass hier mit etwas mehr Code eine entsprechende Lösung auch funktionieren könnte - damit habe ich mich aber noch nicht beschäftigt...

Grüße